Re: [Snort-users] [Emerging-Sigs] GPL rules - who maintains them? Nobody?
evil...@packetmail.net
Hash: SHA1
On 03/18/11 19:23, Jason Brvenik wrote:
> Make sense? What's missing?
Performance degradation, elimination of false positives/false negatives as the
Internet and applications evolve, etc.
If an improvement is made, and deemed and improvement, it makes sense to include
it into ET/VRT, or vice versa; remember these are community/GPL rules and not
VRT IP.
There are two ET sets, open, and open-nogpl, with the open set including GPL
rules overlapping with the VRT community rules. There are organizations which
only run ET, so inclusion of the gpl rules in the 'open' set makes sense. For
dual-subscribers (ET & VRT) the 'open-nogpl' rules make sense.
It was decided to not change the SIDs to avoid performance degradation, lack of
continuity in the GPL rules, etc. So, if the VRT team makes changes to the GPL
rules we'd (ET [1]) appreciate the updates. Conversely, if we (ET [1]) make
changes we'd like to submit these to VRT as well, and come to an agreement for
the sake of uniformity.
[1] I should say I am a ET community participant only and have no profit to
derive from my participation. I'm actually speaking presumptuously for ET, but
I think there's a desire in cooperation between both organizations. Just
bringing you up to speed.
Now, it's beer time.
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNg/tfAAoJENgimYXu6xOHREcQAIeJqB6fswDUAuqFZaOnmh1L
580kbHvhSKap845SiLWcaYucZ8vtdbKdUZlts2lrLnmlWUEfWkpsF+sQy92hh8As
QMWfopV3KpLmlRul8RcqOYot3+Bec/KLuBUJKZjFBvJJ56Mg6BaExjxmZ0x13hLd
2I/RMd1MYWQqZ9ADJ9FKOdPSX9ouiRfQJD6UxwDcUypNSRvAA/TVnyBq6i1XqFpA
saP+HwgUyykiFz+YAd4UQUPjGJBBYdivBn4CRVrjsMfLUYo1C6BUTbj78qKdBNHn
g6Vvk79TxzUympGVwN+P4XYkU5pHwIEMTPNRCB+YfkpVXnmvL473NAiYqlBqvQwt
/7sO6TuemkZK6Gfub4mbpe09xpfNN7GVs3aNoikVVzo2HX6OIwS9FPo3nxP3Qiqj
WG5G5HdYYW3ItlDmkzPylH7b8eYYxiIqaKnwODWiCfgEqwTfd1mZJYCRmI+Bd9iJ
pyjo1KLX4OliONiu+6OJwdWqNQO3m6UBOwmylC+tZNfqrH/TvxOFk0ojS8Q9Q7a+
S5kcRr1/VUcytCjkOQlTSGDMN8u4m2CPlcT+ZOxXShGImKOgFyrnzjiwYLtH1Oz7
RnaXpEK8ocGhJUl5NHxMNAABe6Fe1DqP/VrqLSSDbGOcVslNW9GwD+f4YanhDdZl
wM2+S0Oh2MWyq2CwLT6y
=WIlQ
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
Joel Esler
> On 03/18/11 19:23, Jason Brvenik wrote:
>> Make sense? What's missing?
>
> Performance degradation, elimination of false positives/false negatives as the
> Internet and applications evolve, etc.
>
> If an improvement is made, and deemed and improvement, it makes sense to include
> it into ET/VRT, or vice versa; remember these are community/GPL rules and not
> VRT IP.
Let's refer to these as "GPL rules" to avoid confusion with the "community" set that Sourcefire was producing before the Snort.org redesign.
> There are two ET sets, open, and open-nogpl, with the open set including GPL
> rules overlapping with the VRT community rules. There are organizations which
> only run ET, so inclusion of the gpl rules in the 'open' set makes sense. For
> dual-subscribers (ET & VRT) the 'open-nogpl' rules make sense.
>
I agree with Jason's suggestion that if ET wants to use the rules, then re sid them, using the original SID as a reference. Heck use reference:url,www.snort.org<whatever the link is to our documentation>; I agree with non-duplication of the sids.
> It was decided to not change the SIDs to avoid performance degradation, lack of
> continuity in the GPL rules, etc. So, if the VRT team makes changes to the GPL
> rules we'd (ET [1]) appreciate the updates. Conversely, if we (ET [1]) make
> changes we'd like to submit these to VRT as well, and come to an agreement for
> the sake of uniformity.
I have an idea for that, but I am not going to volunteer it publically until I discuss it with Sourcefire internally to make sure we can do it. If ET would like to submit changes, I encourage them to do so. The OSSRC was formed to deal exactly with this issue, however, it seems as if not only the OSSRC has fallen off, but the communities that formed it have come up with different goals.
For example, detection was supposed to be unique. However, now, there are rules that cover the same "things" in both rulesets. OSSRC was there to manage duplication of this kind of thing and the transition of rules from the ET ruleset over to VRT. It's obvious to me that isn't going to happen anymore. Ref: ETPRO.
>
> [1] I should say I am a ET community participant only and have no profit to
> derive from my participation. I'm actually speaking presumptuously for ET, but
> I think there's a desire in cooperation between both organizations. Just
> bringing you up to speed.
The Snort community is a big world. Getting a lot bigger recently (I've seen registration and traffic increase). Input from all forms is good.
--
Joel Esler
jesler () sourcefire.com
http://blog.snort.org && http://blog.clamav.net
Twitter: @snort
evil...@packetmail.net
Hash: SHA1
On 03/18/11 20:14, Joel Esler wrote:
> The Snort community is a big world. Getting a lot bigger recently (I've seen registration and traffic increase).
Not just that, Suricata too, which is really showing promise. I wonder if we'll
see a new life in Snort with perhaps some innovations seen in Suricata making
it's way into Snort.
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNhAfmAAoJENgimYXu6xOHg7gP/3YQ+c+ZnWDysC8ipQUMVS07
olqZPWp7/LCnkzgaJ47eXuhx/vHxw/oAF+jI5nozoHiCYKJjWPYu7Cm6We9zO7BY
H6MmyliPr+8M/IM8gk1pckD3ARH+Uu38ybomGxG5JKASa26O+D8BScri2bHJ3pJW
CzLubvOT7annXg3lUny7xZZXGxwEDHn725ytXMRvDAzqpL2s0tSTvq/lcAcuwU7c
xvqxwAtFVS3uHVrhO6VTLgo0SFO2PSL89mqM4uULV5gQGMCfepNLXIohedxW7y6D
v8IdT2VQJeRbZ1PMyJSO1WBkOYSbFZtJVlNgnbNFP5e6KvOgiRO/L14zytMxFdPr
TXjVqn9g1u/sk2/zklSOV9EsemHkqzaHzlwexBGOOO5SGb5soV5Q5YJI/IaG7ZpL
aJ06MyZGNKCBv9mzN3CXb1CaJ9/HoUqIQg4RaO90ggcXvQ3WN31DsYUxUpBxS1dV
QAKZcIgOf3ZP5wcLHP113DjXPH6og0Jj7pxLnHDF3S+w20TFcq14SFsDZ3sPsUbW
ePTKVajO96MxwLQAgPIJLVV20l1t2poyI7ck94wP9irsBvYGLjNCQwIrI1JUYNgU
lWNgmjSf7sd1WWwugsijTBkjyY1r9IGNUsATOVlVGSxs4p8gNQ6rmWYD+VOf8mI+
2hACPQyqebeKGZJn7Ija
=c5Cp
-----END PGP SIGNATURE-----
Matthew Jonkman
On Mar 18, 2011, at 9:14 PM, Joel Esler wrote:
>> It was decided to not change the SIDs to avoid performance degradation, lack of
>> continuity in the GPL rules, etc. So, if the VRT team makes changes to the GPL
>> rules we'd (ET [1]) appreciate the updates. Conversely, if we (ET [1]) make
>> changes we'd like to submit these to VRT as well, and come to an agreement for
>> the sake of uniformity.
>
> I have an idea for that, but I am not going to volunteer it publically until I discuss it with Sourcefire internally to make sure we can do it. If ET would like to submit changes, I encourage them to do so. The OSSRC was formed to deal exactly with this issue, however, it seems as if not only the OSSRC has fallen off, but the communities that formed it have come up with different goals.
>
> For example, detection was supposed to be unique. However, now, there are rules that cover the same "things" in both rulesets. OSSRC was there to manage duplication of this kind of thing and the transition of rules from the ET ruleset over to VRT. It's obvious to me that isn't going to happen anymore. Ref: ETPRO.
>
The ET ruleset is not intended to be an add-on for VRT anymore. It can be used that way, but we are not going to NOT cover an issue we have intel in on the community because VRT might put something out a week later. Sorry, that arrangement was over years ago. Please understand, ET Open and ET Pro are independent rulesets. We are not here to feed rules into the VRT ruleset, although you are perfectly free by license to take them as you like. But we are publishing them in more formats and versions, so if anything is to be a master repository it should be the one with the super-set of versions and formats.
VRT is welcome to pull the 1 or 2 engine versions they'd like out of ours and use them commercially. They're BSD licensed on purpose. That would actually eliminate more duplication if VRT were to pull the rules that they like and then people wouldn't have to combine the open set with VRT. And that'd be perfectly file, these are BSD licensed and put out there for people to use commercially if they like. Hundreds of companies and projects repackage these rules and we love it!
So why don't we go down that road? Instead of trying to avoid duplication when people combine, why not make VRT a complete ruleset on it's own? Then no more combination issues and duplication.
Matt
>>
>> [1] I should say I am a ET community participant only and have no profit to
>> derive from my participation. I'm actually speaking presumptuously for ET, but
>> I think there's a desire in cooperation between both organizations. Just
>> bringing you up to speed.
>
> The Snort community is a big world. Getting a lot bigger recently (I've seen registration and traffic increase). Input from all forms is good.
>
>
> --
> Joel Esler
> jesler () sourcefire.com
> http://blog.snort.org && http://blog.clamav.net
> Twitter: @snort
>
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Jason Brvenik
<evil...@packetmail.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> Define "them" please
>>
>> Is your assertion that users don't need to run VRT and ET Rules sets?
>
> He's talking about GPL duplication across both the VRT and ET sets, there's no
> point to run true duplicated rules, matter of fact it results in SID collision
> and breakage.
>
> So, if ET is making changes to these GPL rules, hopefully they'll be committed
> into the VRT set (if they're not deprecated) so that there is uniformity across
> both rule sets.
ok. Sure. Submit the changes and if they are appropriate I'm confident
they will be committed.
That being said. Rule duplication is bad all around and actively
maintaining duplication is bad form at best, especially if the
duplicates are not exact copies. I can somewhat understand a desire to
maintain a copy of the rules set but not to actively distribute
duplication, that just hurts users. I believe this is driven by the
potential for updates or for the situation where a suggested change is
not committed for any reason.
IMHO the potential update conflict is easy to resolve... Create a new
rule, assign a new SID in the appropriate range, and add the old rule
SID and it's source as a reference. This solves the problems of
duplication, natural change, divergence in purpose, etc without
causing the users pain.
Make sense? What's missing?
>
> - --
> It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
> strong.
>
> - -evilghost
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBAgAGBQJNg+/aAAoJENgimYXu6xOHYsEP/0HtXypl/Jno92agj7F0A/92
> qc9tD6ma/oXV60CLvFXoYERZG7/DuT51E5b9rr+p/U2awh3WUVRdT6mPrtj7rlbJ
> qTDWDmuTPUryJBU1EYTdTwroLEZCYR1lp02OrBIAjKMtUDYqMyFTInkTon4JkiYo
> JRK9NeeYV62XXL1fVxWCRty1D4BfMIhWbBp+5tntgxXdbvjj2CL5C8afrGeiwBgF
> QazLhx/MQy8nFAw90zxapc7J7GOpQ7loXo/iyjvpG6J8BH+f1S6vubJXE1qXlWFx
> Mkyk/odwrEv//Rcj5aYaei5y2YpL1un4n+wKlyQCThzJUZ85LYW4OqrbD9TILidY
> Dh7QV37K/zPRuAINd7YVrHuevFpwiIb+CgSgmwwEGOhTN74KbvKmKtZNLLgwUQhr
> 9mRnHHBdjxekQ6CjgN9zJM9vo/7yd5MTjkKHzwcIF50DDlSMPG2p91r9FLIRV56n
> kS5Agg69sUzHt+EgXOq2qeNY00nGy36Kvt5Gega3em3SUkm2pc0YE+pETgF+CLAS
> AdoC//lIJohxKMuhlb67DnnPgACootPh5mDReOqUMEzA5BEWGa3vWf0ssNXe7Hpr
> npqnSR1uIu/Z1SPeTDA+Cot5FddtPnMAzWJSfRp3QB/5ehnxALtlk6xQUd1tcAYO
> kbsTjJpGbJZw/KD8nqi5
> =o0bj
> -----END PGP SIGNATURE-----
Matthew Jonkman
1. Speed of updates. ET Open and Pro rulesets update about daily. You submit something it's changed in 24 hours and published. VRT is weekly at best (still astounds me that people accept that... would AV updates be ok that slow? Why IDS?). I don't think this community will work well with a week or longer update cycle, especially if we're waiting for approval from vrt to make a change in a gpl sig. We just operate differently, and I don't see easy collaboration there. If we make a change on our schedule and vrt disagrees a week later we have unnecessary overhead and flipflop.
2. We've been hashing over collaboration between vrt and SF and ET for what, 7 years now? Every time it's come down to SF saying no, we can't do that because it's not in our commercial interest. I frankly just don't believe it will be any different this time (try number 62). I know you're sincere about wanting to collaborate Joel and Jason, but I just don't believe anything can come of it from above. We all get along great at the personal level, the VRT team and the ET team and communities are both great people at the top of their games that help each other when needed. But when the approval process of SF comes into play it always gets stopped. So we're best off with informal agreements as we've been doing for years.
3. Lets be clear here. The ET ruleset is NOT here for VRT to pick the best of and consume making VRT some kind of uber-ruleset and then we'll drop whatever VRT consumes out of the ET ruleset. The ET ruleset is NOT a secondary or sub-par ruleset. This ruleset stands on it's own, it's independent, and frankly it's better than VRT because of the community that runs it and the speed at which we cover malware. OSSRC may have been appropriate 5 years ago, but those days are gone. So lets talk on an equal playing field or not at all.
4. The ET Open ruleset will continue to flourish as the community stays involved and keeps making it great, and we keep taking and pushing the intel they share in a timely manner. It'll also flourish as the ET Pro ruleset remains a commercial success to support the open ruleset which also gives folks one place to get all the mainstream vulns plus the malware without duplication. So at the end of the day we are competitive. Closer collaboration will very likely not sit well with the SF management team. So why are we pretending it might?
5. We have many more versions of the rules available, including Suricata and many more back versions of Snort. So if there is a master set of the rules to be maintained it should be here, not at VRT. VRT can then pull the limited versions they publish. That makes perfect logical sense, so lets talk about that. We will take whatever changes VRt proposes and integrate them within 24 hours, and it'll still be within the update cycle of vrt. And you'll have many more versions available to you should you choose to quit end of life-ing active products.
I realize I've come off a bit dick-ish the last couple days. Perhaps I'm ovulating. But the above is how I see things, and I don't believe this time will be different with sourcefire. ("Please come back baby, I swear won't hit you... again..." ) I'm just not buying it.
Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work for the largest security vendor in the space who's only goal is to get more market share to jack up the share price while everyone prepares to cash out, or get yourselves bought by one of the big 5. Having a larger and faster moving ruleset doesn't get that market share (A long list of cve's covered does, so malware isn't a priority) so I am dubious there will be any movement here.
But at the end of the day I'm just one guy in the ET community, and this community does what this community as a whole wants. So I've laid out my thoughts on collaboration, and I don't believe it'll work unless we maintain that repository since we produce more versions and platforms.
Thoughts? This is the decision of the ET community, so please weigh in! I'm sure some will disagree and lambaste me (Paul, where are ya?) but I want to hear it all. We'll decide what to do together.
Matt
On Mar 18, 2011, at 7:50 PM, evil...@packetmail.net wrote:
> * PGP Signed by an unverified key: 3/18/11 at 7:50:50 PM
>
> On 03/18/11 18:45, Jason Brvenik wrote:
>> Define "them" please
>>
>> Is your assertion that users don't need to run VRT and ET Rules sets?
>
> He's talking about GPL duplication across both the VRT and ET sets, there's no
> point to run true duplicated rules, matter of fact it results in SID collision
> and breakage.
>
> So, if ET is making changes to these GPL rules, hopefully they'll be committed
> into the VRT set (if they're not deprecated) so that there is uniformity across
> both rule sets.
>
> --
> It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
> strong.
>
> -evilghost
>
> * evil...@packetmail.net <evil...@packetmail.net>
> * 0xEEEB1387 - Unverified(L)
>
>
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Jason Brvenik
<jon...@emergingthreatspro.com> wrote:
> On Mar 18, 2011, at 7:45 PM, Jason Brvenik wrote:
>
>> On Fri, Mar 18, 2011 at 5:32 PM, Matthew Jonkman
>> <jon...@emergingthreatspro.com> wrote:
>>> You make a good point, but I fear that'd be more confusing.
>>> If the sids aren't the same then folks will assume they're different rules,
>>> and run them all.
>>> The average new snort/suricata user gets rule crazy (I remember doing it :)
>>> ) and just downloading and enabling everything they can find. I think we'd
>>> end up wasting a lot of cpu cycles....
>>> But I'm flexible. We're a community. Lets decide together. I've voted for
>>> keeping them the same, because we don't have a need to run them at the same
>>> time, and they're GPL so it's free use.
>>
>> Define "them" please
>>
>> Is your assertion that users don't need to run VRT and ET Rules sets?
>>
>
>
> In fact, we'll cause issues IF we put them in different sid ranges because folks will assume they need to run both then...
Instead we have a situation where old rules are deprecated,
superseded, colliding, etc. I think that in general folks assume they
need both already, enlightenment comes later. Causing new users pain
for what amounts to an ideological position. I don't believe
duplicating them in any form is appropriate unless there is a
divergence in what they do and detect thus creating a new rule.
Ultimately I posit that duplication of inspection content and not SID
isn't going to change things greatly compared to the use of 10K+ rules
already deployed from both sets and the clear pain it presents to new
and longs standing users.
>
> Matt
>
>
>>> Thoughts?
>>> Matt
>>> On Mar 18, 2011, at 5:20 PM, Weir, Jason wrote:
>>>
>>> Seems to me it might be time for ET to re-name and re-sid those rules.
>>>
>>> Then VRT and ET can go in whatever direction they deem appropriate. Without
>>> confusing the user base.
>>>
>>> Yes it means more rule overlap but that's something us end users are dealing
>>> with already..
>>>
>>> -J
>>>
>>>
>>> ----- Original Message -----
>>> From: Matthew Jonkman <jon...@emergingthreatspro.com>
>>> To: Joel Esler <jes...@sourcefire.com>
>>> Cc: Weir, Jason; Emerging Threats Threats Signatures
>>> <emergi...@emergingthreats.net>; waldo kitty <wkit...@windstream.net>;
>>> snort...@lists.sourceforge.net <snort...@lists.sourceforge.net>
>>> Sent: Fri Mar 18 16:40:41 2011
>>> Subject: Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?
>>>
>>> The issue is though that VRT won't support versions back to snort 2.4, nor a
>>> version for suricata, which we do at ET. So we have the gpl rules here as
>>> well in the ET ruleset.
>>>
>>> If that could be worked out we could integrate, but I think SF has made it
>>> clear their stance on suricata, and on snorts more than 2 versions back.
>>>
>>> Matt
>>>
>>>
>>> On Mar 18, 2011, at 3:20 PM, Joel Esler wrote:
>>>
>>>> That was a porn rule. Which we've gotten rid of.
>>>>
>>>> Rules that are <1,000,000 in SID are officially maintained by the VRT
>>>> (even the sids that were available before the VRT license change -- commonly
>>>> referred to as "gpl rules").
>>>>
>>>> Emerging threats is encouraged to submit any changes to the ruleset to
>>>> sids <1,000,000 back to the VRT for inclusion into the VRT set. However,
>>>> the numbers should not be duplicated.
>>>>
>>>> J
>>>>
>>>> On Mar 18, 2011, at 3:04 PM, Weir, Jason wrote:
>>>>
>>>>> That is the raw packet data - as outputted by BASE anyways..
>>>>>
>>>>> That rule is in the ET set here
>>>>>
>>>>> http://rules.emergingthreats.net/open/snort-2.9.0/emerging-all.rules
>>>>>
>>>>> -J
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: waldo kitty [mailto:wkit...@windstream.net]
>>>>>> Sent: Friday, March 18, 2011 2:53 PM
>>>>>> To: Weir, Jason
>>>>>> Cc: emergi...@emergingthreats.net
>>>>>> Subject: Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?
>>>>>>
>>>>>>
>>>>>> On 3/18/2011 13:56, Weir, Jason wrote:
>>>>>>> After I spammed the snort sigs list on this - looks like it
>>>>>> came with
>>>>>>> the ET rules..
>>>>>>>
>>>>>>> It's probably not maintained by anyone but I'm seeing what
>>>>>> could be a FP
>>>>>>> on 1313
>>>>>>
>>>>>> sid:1313; does not exist in my setup with both VRT and ET
>>>>>> rules sets... not even
>>>>>> as a commented line...
>>>>>>
>>>>>>> Here's the data - no "up skirt" that I can see....
>>>>>>
>>>>>> is that the raw packet data?
>>>>>
>>>>>
>>>>>
>>>>> _____________________________________________________________________________________________
>>>>>
>>>>> Please visit www.nhrs.org to subscribe to NHRS email announcements and
>>>>> updates.
>>>>> _______________________________________________
>>>>> Emerging-sigs mailing list
>>>>> Emergi...@emergingthreats.net
>>>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>>>
>>>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>>>> http://www.emergingthreatspro.com
>>>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>>>> Current!
>>>>
>>>> --
>>>> Joel Esler
>>>> jesler () sourcefire.com
>>>> http://blog.snort.org && http://blog.clamav.net
>>>> Twitter: @snort
>>>>
>>>> _______________________________________________
>>>> Emerging-sigs mailing list
>>>> Emergi...@emergingthreats.net
>>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>>
>>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>>> http://www.emergingthreatspro.com
>>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>>> Current!
>>>
>>>
>>> ----------------------------------------------------
>>> Matthew Jonkman
>>> Emergingthreats.net
>>> Emerging Threats Pro
>>> Open Information Security Foundation (OISF)
>>> Phone 765-807-8630 x110
>>> Fax 312-264-0205
>>> http://www.emergingthreatspro.com
>>> http://www.openinfosecfoundation.org
>>> ----------------------------------------------------
>>>
>>> PGP: http://www.jonkmans.com/mattjonkman.asc
>>>
>>>
>>>
>>>
>>>
>>> _____________________________________________________________________________________________
>>>
>>> Please visit www.nhrs.org to subscribe to NHRS email announcements and
>>> updates.
>>>
>>> _____________________________________________________________________________________________
>>>
>>> Please visit www.nhrs.org to subscribe to NHRS email announcements and
>>> updates.
>>>
>>> _______________________________________________
>>> Emerging-sigs mailing list
>>> Emergi...@emergingthreats.net
>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>> Current!
>>>
>>> ----------------------------------------------------
>>> Matthew Jonkman
>>> Emergingthreats.net
>>> Emerging Threats Pro
>>> Open Information Security Foundation (OISF)
>>> Phone 765-807-8630 x110
>>> Fax 312-264-0205
>>> http://www.emergingthreatspro.com
>>> http://www.openinfosecfoundation.org
>>> ----------------------------------------------------
>>>
>>> PGP: http://www.jonkmans.com/mattjonkman.asc
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Emerging-sigs mailing list
>>> Emergi...@emergingthreats.net
>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>> Current!
Jason Brvenik
<jon...@emergingthreatspro.com> wrote:
> I would like uniformity. I think we would agree on most of the changes in the gpl rules between ET and VRT. But there will be issues I suspect:
>
> 1. Speed of updates. ET Open and Pro rulesets update about daily. You submit something it's
> changed in 24 hours and published. VRT is weekly at best (still astounds me that people
> accept that... would AV updates be ok that slow? Why IDS?). I don't think this community will
> work well with a week or longer update cycle, especially if we're waiting for approval from vrt
> to make a change in a gpl sig. We just operate differently, and I don't see easy collaboration
> there. If we make a change on our schedule and vrt disagrees a week later we have
> unnecessary overhead and flipflop.
We do operate differently, for good reason. Our customers demand
stability and effectiveness.
Because our customers demand stability and effectiveness doesn't mean
you can't create a new rule and run with it, referencing the old is
perfectly acceptable.
For clarification, we generally publish Tuesdays and Thursdays but if
there is cause will publish out of cycle.
>
> 2. We've been hashing over collaboration between vrt and SF and ET for what, 7 years now?
> Every time it's come down to SF saying no, we can't do that because it's not in our
> commercial interest. I frankly just don't believe it will be any different this time (try number
> 62). I know you're sincere about wanting to collaborate Joel and Jason, but I just don't
> believe anything can come of it from above. We all get along great at the personal level, the
> VRT team and the ET team and communities are both great people at the top of their games
> that help each other when needed. But when the approval process of SF comes into play it
> always gets stopped. So we're best off with informal agreements as we've been doing for
> years.
If that were true the snort engine would have gone the path of nessus ages ago.
>
> 3. Lets be clear here. The ET ruleset is NOT here for VRT to pick the best of and consume
> making VRT some kind of uber-ruleset and then we'll drop whatever VRT consumes out of the
> ET ruleset. The ET ruleset is NOT a secondary or sub-par ruleset. This ruleset stands on it's
> own, it's independent, and frankly it's better than VRT because of the community that runs it
> and the speed at which we cover malware. OSSRC may have been appropriate 5 years ago,
> but those days are gone. So lets talk on an equal playing field or not at all.
Reference from my other mail why this wouldn't happen. Ultimately I
think the problem is perspective, IPS is NOT anti-malware, our
technologies can be used for it but that is not the right way to solve
the problem.
If you really want to start to solve that problem have a look at our
latest acquisition, Immunet (It is free BTW) -
http://www.immunet.com/main/index.html
Immunet convicts malware at a rate well beyond the ability of the
fastest community by the nature of it's design.
>
> 4. The ET Open ruleset will continue to flourish as the community stays involved and keeps
> making it great, and we keep taking and pushing the intel they share in a timely manner. It'll
> also flourish as the ET Pro ruleset remains a commercial success to support the open ruleset
> which also gives folks one place to get all the mainstream vulns plus the malware without
> duplication. So at the end of the day we are competitive. Closer collaboration will very likely
> not sit well with the SF management team. So why are we pretending it might?
That isn't the issue at all. The few users we have that want malware
capability in the IPS are referred to ET, this arrangement works great
if you ask me.
We believe Immunet is a better approach all together, please have a
look at how we do it in a much faster and more effective manner -
http://www.immunet.com/main/index.html
>
> 5. We have many more versions of the rules available, including Suricata and many more
> back versions of Snort. So if there is a master set of the rules to be maintained it should be
> here, not at VRT. VRT can then pull the limited versions they publish. That makes perfect
> logical sense, so lets talk about that. We will take whatever changes VRt proposes and
> integrate them within 24 hours, and it'll still be within the update cycle of vrt. And you'll have
> many more versions available to you should you choose to quit end of life-ing active products.
I don't think this is germane to the conversation about ET not
duplicating rules mastered elsewhere. We should have a separate
conversation about publishing rules for old engines if you want to get
into the topic in depth. I understand that some users can't upgrade
but running an engine that is 6 years old is a disservice and
publishing rules for it is also wrought with ills.
>
>
> I realize I've come off a bit dick-ish the last couple days. Perhaps I'm ovulating. But the above
> is how I see things, and I don't believe this time will be different with sourcefire. ("Please
> come back baby, I swear won't hit you... again..." ) I'm just not buying it.
lol, I think you are a bit upset with Sourcefire, that is ok, but
don't let that keep you from listening to your users.
>
> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason
> or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work
> for the largest security vendor in the space who's only goal is to get more market share to
> jack up the share price while everyone prepares to cash out, or get yourselves bought by one
> of the big 5. Having a larger and faster moving ruleset doesn't get that market share (A long
> list of cve's covered does, so malware isn't a priority) so I am dubious there will be any
> movement here.
Thanks! I didn't know we were the largest, I thought that designation
went to Cisco.
>
> But at the end of the day I'm just one guy in the ET community, and this community does
> what this community as a whole wants. So I've laid out my thoughts on collaboration, and I
> don't believe it'll work unless we maintain that repository since we produce more versions and
> platforms.
>
> Thoughts? This is the decision of the ET community, so please weigh in! I'm sure some will
> disagree and lambaste me (Paul, where are ya?) but I want to hear it all. We'll decide what to
> do together.
>
> Matt
>
>
> On Mar 18, 2011, at 7:50 PM, evil...@packetmail.net wrote:
>
>> * PGP Signed by an unverified key: 3/18/11 at 7:50:50 PM
>>
>> On 03/18/11 18:45, Jason Brvenik wrote:
>>> Define "them" please
>>>
>>> Is your assertion that users don't need to run VRT and ET Rules sets?
>>
>> He's talking about GPL duplication across both the VRT and ET sets, there's no
>> point to run true duplicated rules, matter of fact it results in SID collision
>> and breakage.
>>
>> So, if ET is making changes to these GPL rules, hopefully they'll be committed
>> into the VRT set (if they're not deprecated) so that there is uniformity across
>> both rule sets.
>>
>> --
>> It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
>> strong.
>>
>> -evilghost
>>
>> * evil...@packetmail.net <evil...@packetmail.net>
>> * 0xEEEB1387 - Unverified(L)
>>
>>
>
>
Matthew Jonkman
>
> We do operate differently, for good reason. Our customers demand
> stability and effectiveness.
> Because our customers demand stability and effectiveness doesn't mean
> you can't create a new rule and run with it, referencing the old is
> perfectly acceptable.
>
Ha! Insults aside, I don't understand what you're saying there.
> For clarification, we generally publish Tuesdays and Thursdays but if
> there is cause will publish out of cycle.
>
Cool. Didn't know it was a set thing.
>>
>> 2. We've been hashing over collaboration between vrt and SF and ET for what, 7 years now?
>> Every time it's come down to SF saying no, we can't do that because it's not in our
>> commercial interest. I frankly just don't believe it will be any different this time (try number
>> 62). I know you're sincere about wanting to collaborate Joel and Jason, but I just don't
>> believe anything can come of it from above. We all get along great at the personal level, the
>> VRT team and the ET team and communities are both great people at the top of their games
>> that help each other when needed. But when the approval process of SF comes into play it
>> always gets stopped. So we're best off with informal agreements as we've been doing for
>> years.
>
> If that were true the snort engine would have gone the path of nessus ages ago.
>
Still don't understand. It is true, you've been here no? Nothing we've tried as far as collaboration was ever allowed. Or successful.
>>
>> 3. Lets be clear here. The ET ruleset is NOT here for VRT to pick the best of and consume
>> making VRT some kind of uber-ruleset and then we'll drop whatever VRT consumes out of the
>> ET ruleset. The ET ruleset is NOT a secondary or sub-par ruleset. This ruleset stands on it's
>> own, it's independent, and frankly it's better than VRT because of the community that runs it
>> and the speed at which we cover malware. OSSRC may have been appropriate 5 years ago,
>> but those days are gone. So lets talk on an equal playing field or not at all.
>
> Reference from my other mail why this wouldn't happen. Ultimately I
> think the problem is perspective, IPS is NOT anti-malware, our
> technologies can be used for it but that is not the right way to solve
> the problem.
>
That's sounds very "not my job" to me. If it's a problem, and you can help fix it, why don't you?
But that's just philosophy. We have different ones, they're both ok, depends on your environment. If your AV is 100% then you probably don't need IDS to lend a hand.
> If you really want to start to solve that problem have a look at our
> latest acquisition, Immunet (It is free BTW) -
> http://www.immunet.com/main/index.html
>
> Immunet convicts malware at a rate well beyond the ability of the
> fastest community by the nature of it's design.
>
Ya, they're a good company and looks like great tech. Not really relevant though, and it's windows only. IDS I think is still necessary to pick up the slack. I doubt immunet would even say they're 100%.
>>
>> 4. The ET Open ruleset will continue to flourish as the community stays involved and keeps
>> making it great, and we keep taking and pushing the intel they share in a timely manner. It'll
>> also flourish as the ET Pro ruleset remains a commercial success to support the open ruleset
>> which also gives folks one place to get all the mainstream vulns plus the malware without
>> duplication. So at the end of the day we are competitive. Closer collaboration will very likely
>> not sit well with the SF management team. So why are we pretending it might?
>
> That isn't the issue at all. The few users we have that want malware
> capability in the IPS are referred to ET, this arrangement works great
> if you ask me.
>
I suppose. Haven't seen a referral yet though. I just can't imagine a customer where malware isn't a problem though...
> We believe Immunet is a better approach all together, please have a
> look at how we do it in a much faster and more effective manner -
> http://www.immunet.com/main/index.html
Ya, it is good stuff.
>
>>
>> 5. We have many more versions of the rules available, including Suricata and many more
>> back versions of Snort. So if there is a master set of the rules to be maintained it should be
>> here, not at VRT. VRT can then pull the limited versions they publish. That makes perfect
>> logical sense, so lets talk about that. We will take whatever changes VRt proposes and
>> integrate them within 24 hours, and it'll still be within the update cycle of vrt. And you'll have
>> many more versions available to you should you choose to quit end of life-ing active products.
>
> I don't think this is germane to the conversation about ET not
> duplicating rules mastered elsewhere. We should have a separate
> conversation about publishing rules for old engines if you want to get
> into the topic in depth. I understand that some users can't upgrade
> but running an engine that is 6 years old is a disservice and
> publishing rules for it is also wrought with ills.
I think it is germane, because we're talking about where the master rules might be held if we were to collaborate. I don't think it's appropriate for them to held by an entity that'll not be maintaining the old versions. That's all.
And ya, running an old engine isn't smart, but some folks haven't a choice, and some folks are running other engines that use the old versions, and some folks run Suricata. So there is a definite need for older versions. Just because it's not idea if you are running old snort doesn't mean there isn't a need for the old versions.
>
>>
>>
>> I realize I've come off a bit dick-ish the last couple days. Perhaps I'm ovulating. But the above
>> is how I see things, and I don't believe this time will be different with sourcefire. ("Please
>> come back baby, I swear won't hit you... again..." ) I'm just not buying it.
>
> lol, I think you are a bit upset with Sourcefire, that is ok, but
> don't let that keep you from listening to your users.
>
:) No not sourcefire. Sourcefire's policies send us a lot of commercial subscribers. You're our best marketing tool. :)
Annoyed I think of late at the overtures for collaboration. It's the same old thing over and over and it is getting in the way of the ET Open rulesets development.
>
>
> Thanks! I didn't know we were the largest, I thought that designation
> went to Cisco.
>
I'm trying to call you largest market share. But if you want to be number 2 that's fine. :)
Matt
>>
>> But at the end of the day I'm just one guy in the ET community, and this community does
>> what this community as a whole wants. So I've laid out my thoughts on collaboration, and I
>> don't believe it'll work unless we maintain that repository since we produce more versions and
>> platforms.
>>
>> Thoughts? This is the decision of the ET community, so please weigh in! I'm sure some will
>> disagree and lambaste me (Paul, where are ya?) but I want to hear it all. We'll decide what to
>> do together.
>>
>> Matt
>>
>>
>> On Mar 18, 2011, at 7:50 PM, evil...@packetmail.net wrote:
>>
>>>> Old Signed by an unverified key: 3/18/11 at 7:50:50 PM
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>>
----------------------------------------------------
evil...@packetmail.net
Hash: SHA1
On 03/19/11 11:44, Jason Brvenik wrote:
> If you really want to start to solve that problem have a look at our
> latest acquisition, Immunet (It is free BTW) -
> http://www.immunet.com/main/index.html
I'm always weary when a security vendor offers panacea, especially when said
panacea depends on the number of participants in the solution. This model
doesn't work quite so well in the spam arena and I doubt malware to be much
different. A hostile endpoint serving up multi-packed goodness, generated on a
per host basis, seems like one very easy way to defeat this system (if I
understand it correctly)
In practice, how well does this work when you're the first guy to get nailed
with fun?
Curious... I like using the best tool for the job and defense and depth and to
assign all malware to a HIDS is presumptuous and perhaps misplaced faith.
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNhTvkAAoJENgimYXu6xOH7VEP/1IX2LsPl7vdEqUptsXroyyc
ogcHnA27CEF+6UTs8Hb7tQWqjjm256SAsYuZyzDD+Cn2XpQFQurOTouxSUMtgL9O
s+rpVFj/mtYkSpBBOaiARqk/fO5Lbr0qUEVPFM5nSjnXZK6J/unfwFVA6X/Z5BJT
BsWAKakMRg8v21DCX7fmyiE6g/qKhqEs1ce4VAgKs6mdlUUMOono9bHQNISux9pn
1adwB2vCQZVA94GA1PO4WNP8ETQ7Hk6L/siMyFanGE5UMyPfYJzdk3xeTTWxeOa4
Tf776I7BE9mTTgXhjjFyPle13hoGpmH08JrNG61Q72XxNm3Erf3ff5F+wp7ZAkeF
0Q3gbZE2pa7tasO4Sl1Z/+kCQgKMZgaOzp6wPjVWXS7Yxg6eDeA/M55Sin3rb5Jq
+aE0pzZrnFxlyKHHbEFKnI7xWBglJVbDashiPH+VUGP4xEubs6aEGexNoFbKjwl7
ED0q5bV/u4/5gpejTbiqJtOPPCxlpNWz5zgc8K7BamfVirGKPRtKHN6vjrnfgYyq
5XJUmqTXL3Q0Jd8OeWOL8qkVUyiHOsENfO5PWrXeZyhW5thUf60COurldFX9MYOE
VxmQwuDnlfrMiMeAYTzpy/3fzHTDX3G7MqCeRnMIzSkmLtC5q5pVGuRXVN3VPGkM
KJUOElt7/cw41p8eeuoh
=fFXh
-----END PGP SIGNATURE-----
Martin Roesch
<evil...@packetmail.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/19/11 11:44, Jason Brvenik wrote:
>> If you really want to start to solve that problem have a look at our
>> latest acquisition, Immunet (It is free BTW) -
>> http://www.immunet.com/main/index.html
>
> I'm always weary when a security vendor offers panacea, especially when said
> panacea depends on the number of participants in the solution. This model
> doesn't work quite so well in the spam arena and I doubt malware to be much
> different. A hostile endpoint serving up multi-packed goodness, generated on a
> per host basis, seems like one very easy way to defeat this system (if I
> understand it correctly)
It works exceedingly well at this particular scenario due to it's
design. The people who designed it did so as a response to how
ineffectual classic AV models have become. It is a "clean sheet"
approach to solving the problem and we did the acquisition after we
saw just how powerful the approach is.
> In practice, how well does this work when you're the first guy to get nailed
> with fun?
Very.
> Curious... I like using the best tool for the job and defense and depth and to
> assign all malware to a HIDS is presumptuous and perhaps misplaced faith.
It's free so you can check it out anytime.
Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
Martin Roesch
<jon...@emergingthreatspro.com> wrote:
> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work for the largest security vendor in the space who's only goal is to get more market share to jack up the share price while everyone prepares to cash out, or get yourselves bought by one of the big 5.
Seriously? Our only goal is share price and cashing out? Our goal is
to build great products that solve hard problems to give our customers
the capability to defend themselves effectively. There's a ton of
technology under the covers that makes all that happen (Snort, RNA,
RUA, Immunet, Razorback,etc).
We don't make any claims to being the company with the largest market
share in the industry but neither does Porsche. I'm fine with being a
minority in the market if I'm the best.
evil...@packetmail.net
Hash: SHA1
On 03/19/11 19:40, Martin Roesch wrote:
> The people who designed it did so as a response to how
> ineffectual classic AV models have become. It is a "clean sheet"
> approach to solving the problem and we did the acquisition after we
> saw just how powerful the approach is.
I think we're all in agreement with this one since the AV model is a false hope
(I know, painful words since you own Clam). I'm jaded and biased after years of
the AV vendors milking a subscription model based on
signature-driven/hash-driven detection which does little to combat the threat.
I'll give this one a whirl, though I'm also weary of "in the cloud" since the
marketing droids like to sling this buzzword to the same magnitude I like to
ingurgitate alcohol.
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNhVkeAAoJENgimYXu6xOHujUP/0+DFORh3Kdaxrf+0fNiZOK2
LVi0kwjR9ueZ2wYv09DmC8rSBwLcc0mxyknLN+8ijmjnMaDmKk7K9peHRtGGMr5+
uWVvv2AKUvQOiaf7BcMY26kGGPK5XOLuxlvWyesJiTf/6VoCzZZ1Mjbv7fXwVr59
yt3H1Gf0JUjlnCN+r7KC+Hi9Ry73gpVi3I4u4rdB4rbxorW6dnfNNioe4nZIs/6V
1Wdw9uu7jiytm7F9M5tMsjh4EfKKh1jkFoqSAGKDjoPjXqL1rQ7OhG8d8jg379MO
QclOgFlL4IY25fhC5GTJxOw23xkRHDsn4SUESSTIR5UfF6rToClRyCG42NyHiNek
r9yaQQUwsfSJs12sVJ0A8l84bV6hN3KnAhX0rWHWdFoG8AIevtVYrkUQjJgpzHKo
FyebE8rACD7dCcP/NoqMHzPcKHSIvguIMXYdGWP0uu8w4iSSCRQfgXfJ+dT72evV
TRYgjuf7C2zT6aRPB8U2hquyXssRLeXEV+GIUpp9bQadRXArYIeohN311BpApczP
UeUDcO1b8ffWEcWm0ZXAVFy8Xq8+awSLFmu/Oaz72o7AtbEY5WJbOxe/YMSZvk2P
bMdNnXlAkIL9bnz13N+Bomh3h9geaoXDR92xci2egb3Xm0PQA2MsBggt7GdA+zQE
5irBn0LgUS2L6oyfVQWD
=QkaJ
-----END PGP SIGNATURE-----
Martin Roesch
<evil...@packetmail.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/19/11 19:40, Martin Roesch wrote:
>> The people who designed it did so as a response to how
>> ineffectual classic AV models have become. It is a "clean sheet"
>> approach to solving the problem and we did the acquisition after we
>> saw just how powerful the approach is.
>
> I think we're all in agreement with this one since the AV model is a false hope
> (I know, painful words since you own Clam).
Clam is great at what it does and is still driven by its original open
source team, I think the ability to write your own sigs is very useful
in general. Immunet 3.0 integrates the ClamAV technology so that you
can get the best of both worlds, custom sigs + the ClamAV team's
coverage (when you want a more traditional AV) in addition to the
collective detection model that Immunet brings to bear.
> I'm jaded and biased after years of
> the AV vendors milking a subscription model based on
> signature-driven/hash-driven detection which does little to combat the threat.
> I'll give this one a whirl, though I'm also weary of "in the cloud" since the
> marketing droids like to sling this buzzword to the same magnitude I like to
> ingurgitate alcohol.
Cloud is the word people use to describe it so that's what we're stuck
with. I think being able to offer more comprehensive client-side
attack detection/prevention is a worthwhile goal and that's what this
technology is designed to do. Hopefully it'll be something you like!
Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
------------------------------------------------------------------------------
Jason Brvenik
<jon...@emergingthreatspro.com> wrote:
> On Mar 19, 2011, at 12:44 PM, Jason Brvenik wrote:
>>
>> We do operate differently, for good reason. Our customers demand
>> stability and effectiveness.
>> Because our customers demand stability and effectiveness doesn't mean
>> you can't create a new rule and run with it, referencing the old is
>> perfectly acceptable.
>>
>
> Ha! Insults aside, I don't understand what you're saying there.
Wow, really?
My statement was directly related to your misinformed digs at update frequency.
"VRT is weekly at best"
"because VRT might put something out a week later"
etc...
"ET Open and Pro rulesets update about daily. You submit something
it's changed in 24 hours and published."
Our customers want coverage for the threats that affect them delivered
in a timely and effective manner. They want to be able to review them,
test them, etc. They don't a rule for malware variants that is tweaked
for false positives in real-time, they want that handled before the
rule is deployed. Like it or not, fast moving detection for things
that they handle quite effectively with other tools is a burden to
them.
I can help solve lots of things, as can you. Tell me, why don't you
help solve world hunger by growing crops in your back yard? Why don't
you help solve pollution by not using electricity? Why don't you
release rules for every virus? Why don't you build a house with screws
and a hammer?
I've the experience to know what works and what doesn't and I can
assure you that making the AV signature race an IPS problem too isn't
going to work. It might make you feel good about detecting something
but it isn't going to move the line forward one bit.
>
> But that's just philosophy. We have different ones, they're both ok, depends on your
> environment. If your AV is 100% then you probably don't need IDS to lend a hand.
The reality is that abusing one tool because of the inadequacy of
another isn't going to solve problems, it might help in the short run
but it is not a solution. If your pain is really AV use Immunet and/or
ClamAV to solve that problem, not Snort.
>
>
>> If you really want to start to solve that problem have a look at our
>> latest acquisition, Immunet (It is free BTW) -
>> http://www.immunet.com/main/index.html
>>
>> Immunet convicts malware at a rate well beyond the ability of the
>> fastest community by the nature of it's design.
>>
>
> Ya, they're a good company and looks like great tech. Not really relevant though, and it's
> windows only. IDS I think is still necessary to pick up the slack. I doubt immunet would even
> say they're 100%.
>
>>>
>>> 4. The ET Open ruleset will continue to flourish as the community stays involved and keeps
>>> making it great, and we keep taking and pushing the intel they share in a timely manner. It'll
>>> also flourish as the ET Pro ruleset remains a commercial success to support the open ruleset
>>> which also gives folks one place to get all the mainstream vulns plus the malware without
>>> duplication. So at the end of the day we are competitive. Closer collaboration will very likely
>>> not sit well with the SF management team. So why are we pretending it might?
>>
>> That isn't the issue at all. The few users we have that want malware
>> capability in the IPS are referred to ET, this arrangement works great
>> if you ask me.
>>
>
> I suppose. Haven't seen a referral yet though. I just can't imagine a customer where malware
> isn't a problem though...
Malware is a problem and we spent good money on a solution that
approaches the problem in a way that can be successful without being
continually in a signature rat race. Feel free to ask any questions
about the approach after you have given Immunet a try -
http://www.immunet.com/main/index.html
>
>> We believe Immunet is a better approach all together, please have a
>> look at how we do it in a much faster and more effective manner -
>> http://www.immunet.com/main/index.html
>
> Ya, it is good stuff.
>
>
>>
>>>
>>> 5. We have many more versions of the rules available, including Suricata and many more
>>> back versions of Snort. So if there is a master set of the rules to be maintained it should be
>>> here, not at VRT. VRT can then pull the limited versions they publish. That makes perfect
>>> logical sense, so lets talk about that. We will take whatever changes VRt proposes and
>>> integrate them within 24 hours, and it'll still be within the update cycle of vrt. And you'll have
>>> many more versions available to you should you choose to quit end of life-ing active products.
>>
>> I don't think this is germane to the conversation about ET not
>> duplicating rules mastered elsewhere. We should have a separate
>> conversation about publishing rules for old engines if you want to get
>> into the topic in depth. I understand that some users can't upgrade
>> but running an engine that is 6 years old is a disservice and
>> publishing rules for it is also wrought with ills.
>
> I think it is germane, because we're talking about where the master rules might be held if we
> were to collaborate. I don't think it's appropriate for them to held by an entity that'll not be
> maintaining the old versions. That's all.
No, we are talking about duplication of rules already mastered
elsewhere and the problems that is causing for users. If you want to
have a different discussion please start a new thread.
>
> And ya, running an old engine isn't smart, but some folks haven't a choice, and some folks
> are running other engines that use the old versions, and some folks run Suricata. So there is
> a definite need for older versions. Just because it's not idea if you are running old snort
> doesn't mean there isn't a need for the old versions.
Enjoy.
>
>>
>>>
>>>
>>> I realize I've come off a bit dick-ish the last couple days. Perhaps I'm ovulating. But the above
>>> is how I see things, and I don't believe this time will be different with sourcefire. ("Please
>>> come back baby, I swear won't hit you... again..." ) I'm just not buying it.
>>
>> lol, I think you are a bit upset with Sourcefire, that is ok, but
>> don't let that keep you from listening to your users.
>>
>
> :) No not sourcefire. Sourcefire's policies send us a lot of commercial subscribers. You're our best marketing tool. :)
>
> Annoyed I think of late at the overtures for collaboration. It's the same old thing over and over and it is getting in the way of the ET Open rulesets development.
My only interest in entering this thread is to resolve the problems
your actions have created. Duplicating rules for the sake of it has
repeatedly caused problems for users. Several very palatable
alternatives have been suggested and I would like to see that
discussion get back on track.
>>
>>
>> Thanks! I didn't know we were the largest, I thought that designation
>> went to Cisco.
>>
>
> I'm trying to call you largest market share. But if you want to be number 2 that's fine. :)
Sorry, I deal with facts most of the time. I did thank you for the
compliment though.
>
> Matt
>
>>>
>>> But at the end of the day I'm just one guy in the ET community, and this community does
>>> what this community as a whole wants. So I've laid out my thoughts on collaboration, and I
>>> don't believe it'll work unless we maintain that repository since we produce more versions and
>>> platforms.
>>>
>>> Thoughts? This is the decision of the ET community, so please weigh in! I'm sure some will
>>> disagree and lambaste me (Paul, where are ya?) but I want to hear it all. We'll decide what to
>>> do together.
>>>
>>> Matt
>>>
>>>
>>> On Mar 18, 2011, at 7:50 PM, evil...@packetmail.net wrote:
>>>
>>>>> Old Signed by an unverified key: 3/18/11 at 7:50:50 PM
>>>>
>>>> On 03/18/11 18:45, Jason Brvenik wrote:
>>>>> Define "them" please
>>>>>
>>>>> Is your assertion that users don't need to run VRT and ET Rules sets?
>>>>
>>>> He's talking about GPL duplication across both the VRT and ET sets, there's no
>>>> point to run true duplicated rules, matter of fact it results in SID collision
>>>> and breakage.
>>>>
>>>> So, if ET is making changes to these GPL rules, hopefully they'll be committed
>>>> into the VRT set (if they're not deprecated) so that there is uniformity across
>>>> both rule sets.
>>>>
>>>> --
>>>> It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
>>>> strong.
>>>>
------------------------------------------------------------------------------
evil...@packetmail.net
Hash: SHA1
Hi Jason,
On 03/19/11 21:19, Jason Brvenik wrote:
> Malware is a problem and we spent good money on a solution that
> approaches the problem in a way that can be successful without being
> continually in a signature rat race. Feel free to ask any questions
> about the approach after you have given Immunet a try -
> http://www.immunet.com/main/index.html
Looks like this is Win32 only? http://www.immunet.com/plus/requirements/index.html
What's the future hold for the emerging threats since we're seeing an evolution
in malware around the Android "platform", OS X, etc? Very eager to hear the
roadmap if you're willing to share. I still don't think it's fair to say
malware == Win32 and an in-the-cloud HIDS/AV supplement mitigates the need for
an IDS inspecting malware traffic.
I'll drive a nail with a wrench or rock when the hammer is 30 minutes away...
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNhWgDAAoJENgimYXu6xOHD34P/0EOrT0B2Orb0xje7XXIaYEm
uB+PYUmxDiXysarfpO8G/08a5gxnUZSu1HClMFjy2p3UH++3C+N2LIbH31vz1UmE
kfa7GeFYDLzykJpZpUtqNNIAdn7X3m8IHrNmqUR2BABN8XZHfD934pa5HFDtFaIJ
0w37w2fYiP8jcf0FUC2O+nbjIyor/QOYRHMcx4AQWAUHi8mCCj4O76yUJASSncip
zZBZTMEvsiOv7UEKRmA+dJqP5OJDVVkVm8rCTCtXNK+xmNcIgWvnBK9R8ig+nwcO
GEml4zc4BAaDW7NjqybOTk6EDu2RHH2licHzZ3byBcFgyx7jewGtcKHtZFo3zI/5
WxQqtgi/bhdlU3d7ejpvdlGwcQZIKL7XpbOJD3BTJIj4Vb+NjD5TeXvabXQTvePM
m/jgUVObtdjb1nbtWuryB6Qe0TjuCQ/az7trGaZx6znChMB9VqadmmpGuoc1OYbR
W7ccZElEeKX0AzRyqPtU0deDlTg1OV1bbREoV4x5+EHz7HZZKJROX4JrDmo5KKz5
wxz3tbpbcsUEnt3YR0kt9BsRZT8BKP0TH6E7gSM7VKal5OMNw7dLxkEtZLV9teW3
Ge8678vEp6npqvfoV2aAPCHlbFhbCEQYSbKPD6kulqRj9eiwVJ4Pl00sJ/V5BLSB
XUOqg3WA9wrbV8aGtP9m
=REmR
-----END PGP SIGNATURE-----
Jason Brvenik
<evil...@packetmail.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Jason,
>
> On 03/19/11 21:19, Jason Brvenik wrote:
>> Malware is a problem and we spent good money on a solution that
>> approaches the problem in a way that can be successful without being
>> continually in a signature rat race. Feel free to ask any questions
>> about the approach after you have given Immunet a try -
>> http://www.immunet.com/main/index.html
>
> Looks like this is Win32 only? http://www.immunet.com/plus/requirements/index.html
Yes, the focus in on the area where the problem is most prevalent.
>
> What's the future hold for the emerging threats since we're seeing an evolution
> in malware around the Android "platform", OS X, etc? Very eager to hear the
> roadmap if you're willing to share. I still don't think it's fair to say
> malware == Win32 and an in-the-cloud HIDS/AV supplement mitigates the need for
> an IDS inspecting malware traffic.
Right now the focus is on the platform that is most plagued with the
problem. I don't have numbers handy but I think that the issue is on
the order of 5+ nines windows VS others. Also remember that Clam runs
on most platforms and has the ability to create personalized
protections against the personalized threats out there today. It is a
strength it has brought to the table for a long time now.
If you have ideas or things you would like to see on the roadmap feel
free to share off list and I can pass it along.
>
> I'll drive a nail with a wrench or rock when the hammer is 30 minutes away...
Me too. I'll drive a nail with anything I have if I need to but I'm
not going to build a house with a rock and screws.
Martin Holste
Your "Porsche" IDS still can't dynamically detect HTTP. That makes it
not "the best."
Razorback is not yet a viable platform and does not appear to be
anywhere near release candidate. I consider it vaporware until I see
otherwise. I've read through the source code and am unimpressed thus
far. Ruminate IDS, using Vortex IDS, solves the same problem in about
1000 lines of Perl and is extremely effective in the hands of
experienced analysts. Your Razorback problem is simple: you're using
compiled code to do the jobs that scripts should be doing, because
they can implement the thousands of already-written libraries that do
what you're trying to do from scratch. By all means, please prove me
wrong.
@Joel/Jason/Marty
We were a paying SF customer for years and are no longer. The reason
is simple: the rules were not detecting client-side attacks (or many
server-side, for that matter), and SO rules were completely unhelpful
(when they weren't segfaulting). Stability is indeed important as
Joel has pointed out, and SO rules drastically decrease stability.
(Unless, of course, you're running an SF appliance, in which case all
of this is easy... hm...). More important than that, though, is that
the opacity of SO rules means my analysts have to guess. Analysts
should not have to guess at what a rule was designed to look for.
That is why closed-source is ineffective.
Further, stop arguing that your rules are more "polished" or something
than ET. Many spew a ridiculous amount of false positives. Just look
at your ActiveX rules and tell me they are something to be proud of.
What modern malware refers to the CLSID of the ActiveX object it's
going to exploit in clear, non-obfuscated Javascript? Very, very few.
Those rules are useless, as were the majority we saw come through to
provide "coverage" for CVE's. That's why we dropped you guys.
And if you think I'm wrong about this, remember that the customer is
always right.
RE:Immunet: Way, way out of scope here. But while it's been
shamelessly plugged to death on an IDS list, I will point out that for
my large org and many other large orgs, client-side anything is not an
option because we don't have the ability to install things on the
assets we're responsible for. You will find a similar story in a lot
of places. But congratulations on your expanding market which
continues to divert your attention from your company's core
competency.
Lastly, thank you for at least participating in the discussion. I
doubt Symantec, Cisco, etc. would allocate time for this, and I do
appreciate having a real dialogue with people that matter in a
company. I hope that we can do business again someday.
Randal T. Rioux
> On Saturday, March 19, 2011, Matthew Jonkman
> <jon...@emergingthreatspro.com> wrote:
>
>> Let this be VERY clear: I am not impuning the character or
>> community spirit of Joel or Jason or any of the VRT guys. You're
>> all great guys and I enjoy working with you all. But you work for
>> the largest security vendor in the space who's only goal is to get
>> more market share to jack up the share price while everyone
>> prepares to cash out, or get yourselves bought by one of the big
>> 5.
Errr... I do have to speak up here. I've worked with Snort (never for!)
for over a decade, before Marty even had a team let alone a company.
He's a nerd like the rest of us. But there comes a time when your baby
grows up and it is a business - and there is a point where you have to
do things different.
Suricata is funded by all of us US taxpayers, so the mentality is
different. You could ship a product that does nothing and still get paid
- though your grant would be yanked after some bureaucrat notices in a
few years :-)
> Seriously? Our only goal is share price and cashing out? Our goal
> is to build great products that solve hard problems to give our
> customers the capability to defend themselves effectively. There's a
> ton of technology under the covers that makes all that happen (Snort,
> RNA, RUA, Immunet, Razorback,etc).
I will say, and I think this is obvious, Marty values his team first.
Then the technology (which is a product of him and his team) and then
making mad bank. The order of this chain is vital. The last can't happen
if they deliver crap.
> We don't make any claims to being the company with the largest
> market share in the industry but neither does Porsche. I'm fine with
> being a minority in the market if I'm the best.
My only complaint would be the cost of those damn boxes. But I will shut
my trap because a small company named HP/ArcSight signs my checks and
they seem to make with a much higher profit margin :-/
Randy
Matthew Jonkman
Trying to bring this discussion back to GPL sids....
Matt
On Mar 19, 2011, at 8:58 PM, Martin Roesch wrote:
> On Saturday, March 19, 2011, Matthew Jonkman
> <jon...@emergingthreatspro.com> wrote:
>
>> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work for the largest security vendor in the space who's only goal is to get more market share to jack up the share price while everyone prepares to cash out, or get yourselves bought by one of the big 5.
>
> Seriously? Our only goal is share price and cashing out? Our goal is
> to build great products that solve hard problems to give our customers
> the capability to defend themselves effectively. There's a ton of
> technology under the covers that makes all that happen (Snort, RNA,
> RUA, Immunet, Razorback,etc).
>
> We don't make any claims to being the company with the largest market
> share in the industry but neither does Porsche. I'm fine with being a
> minority in the market if I'm the best.
>
>
> --
> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
> Sourcefire - Security for the Real World - http://www.sourcefire.com
> Snort: Open Source IDP - http://www.snort.org
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Matthew Jonkman
>>>
>>> We do operate differently, for good reason. Our customers demand
>>> stability and effectiveness.
>>> Because our customers demand stability and effectiveness doesn't mean
>>> you can't create a new rule and run with it, referencing the old is
>>> perfectly acceptable.
>>>
>>
>> Ha! Insults aside, I don't understand what you're saying there.
>
> Wow, really?
>
Ya. I don't understand the point you're trying to make. The part about create a new rule and run with it and reference the old rule.
Can you elaborate?
> My statement was directly related to your misinformed digs at update frequency.
>
> "VRT is weekly at best"
> "because VRT might put something out a week later"
> etc...
> "ET Open and Pro rulesets update about daily. You submit something
> it's changed in 24 hours and published."
>
> Our customers want coverage for the threats that affect them delivered
> in a timely and effective manner. They want to be able to review them,
> test them, etc. They don't a rule for malware variants that is tweaked
> for false positives in real-time, they want that handled before the
> rule is deployed. Like it or not, fast moving detection for things
> that they handle quite effectively with other tools is a burden to
> them.
>
Sorry, that's not what I was trying talking about. Trying to get back to the GPL sigs.
We do not want to run at the pace of VRT for changes to GPL sigs. So I think collaboration will be very rocky and difficult.
>>>
>>
>> That's sounds very "not my job" to me. If it's a problem, and you can help fix it, why don't you?
>
> I can help solve lots of things, as can you. Tell me, why don't you
> help solve world hunger by growing crops in your back yard? Why don't
> you help solve pollution by not using electricity? Why don't you
> release rules for every virus? Why don't you build a house with screws
> and a hammer?
>
> I've the experience to know what works and what doesn't and I can
> assure you that making the AV signature race an IPS problem too isn't
> going to work. It might make you feel good about detecting something
> but it isn't going to move the line forward one bit.
>
I wouldn't try to solve world hunger because I haven't a tool capable of it.
On malware, I do have a tool and the resources and intel available to make a significant impact. And considering that AV isn't getting any better, I firmly believe that IDS can pick up abother 50% of coverage on the wire, and help cover that 72 hour lead time for a virus to be covered. We have a unique point of view in that while the malware may change and evade AV, they VERY often continue to use the same CnC protocol. So the IDS sigs are more reliable longer.
I know we won't get ALL malware with ids sigs, but we can pick up some slack.
I suspect we'll have to agree to disagree here. But I still don't understand why you guys DO publish malware and spyware sigs if you're this opposed to the concept.
>>
>> But that's just philosophy. We have different ones, they're both ok, depends on your
>> environment. If your AV is 100% then you probably don't need IDS to lend a hand.
>
> The reality is that abusing one tool because of the inadequacy of
> another isn't going to solve problems, it might help in the short run
> but it is not a solution. If your pain is really AV use Immunet and/or
> ClamAV to solve that problem, not Snort.
>
I don't see either of those solving the problem. If I missed a marketing presentation please let me know. Has someone announced 100% coverage AV? I must have missed it.
>>>
>>>
>>
>> I suppose. Haven't seen a referral yet though. I just can't imagine a customer where malware
>> isn't a problem though...
>
> Malware is a problem and we spent good money on a solution that
> approaches the problem in a way that can be successful without being
> continually in a signature rat race. Feel free to ask any questions
> about the approach after you have given Immunet a try -
> http://www.immunet.com/main/index.html
Appreciate the offer. I unfortunately don't have any windows boxes so I can't give it a try. If I ever do I certainly will.
Well, we do have windows boxes, but they're zombies in the sandnet being infected thousands of times a day for writing sigs... :)
>>>
>>
>> I think it is germane, because we're talking about where the master rules might be held if we
>> were to collaborate. I don't think it's appropriate for them to held by an entity that'll not be
>> maintaining the old versions. That's all.
>
> No, we are talking about duplication of rules already mastered
> elsewhere and the problems that is causing for users. If you want to
> have a different discussion please start a new thread.
I don't think it's causing problems for users. We have 2 rulesets published to solve this problem.
What I thought we were discussing was collaborating somehow to keep them in sync. We also have to keep in sync versions for old snort and now for suricata, and we'll be putting them into other formats soon. So I think it makes sense for the "master" repository to be maintained in the community, not at VRT. You'll be end of lifing something we still need over here soon, so then we'd have to maintain those on our own anyway....
So, I'd like to keep talking about this. Why does the master repo of GPL rules have to be maintained at Sourcefire? Especially when the community will have more versions that SF wants to support, and for other platforms that SF has great disdain for.
>>
>
> My only interest in entering this thread is to resolve the problems
> your actions have created. Duplicating rules for the sake of it has
> repeatedly caused problems for users. Several very palatable
> alternatives have been suggested and I would like to see that
> discussion get back on track.
Agreed. I missed the palatable alternatives, perhaps we need to reset the discussion?
Matt
Matt Olney
You wrote this? You don't know anything about what goes on here or
why anyone on the VRT does anything. You aren't an Internet angel or
a savior, you're a self-aggrandizing asshat using this list to pimp
your project. You ARE calling into question the character of Joel and
Jason and the VRT. I'm done with your slander of this group, you
don't know what you're talking about.
Until you have something useful to contribute, on topic, keep your
lies and your ill-informed, manipulative and self-serving comments to
yourself.
I'm not having this conversation, like so many others I've had with
you privately. You've stepped FAR across a line, and an immediate
apology is in order.
Matthew Olney
>> On Saturday, March 19, 2011, Matthew Jonkman
>> <jon...@emergingthreatspro.com> wrote:
>>
>>> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work for the largest security vendor in the space who's only goal is to get more market share to jack up the share price while everyone prepares to cash out, or get yourselves bought by one of the big 5.
>>
------------------------------------------------------------------------------
Matthew Jonkman
This is real life. Please put your emotions away.
MAtt
On Mar 21, 2011, at 10:15 AM, Matt Olney wrote:
> Jonkman,
>
> You wrote this? You don't know anything about what goes on here or
> why anyone on the VRT does anything. You aren't an Internet angel or
> a savior, you're a self-aggrandizing asshat using this list to pimp
> your project. You ARE calling into question the character of Joel and
> Jason and the VRT. I'm done with your slander of this group, you
> don't know what you're talking about.
>
> Until you have something useful to contribute, on topic, keep your
> lies and your ill-informed, manipulative and self-serving comments to
> yourself.
>
> I'm not having this conversation, like so many others I've had with
> you privately. You've stepped FAR across a line, and an immediate
> apology is in order.
>
> Matthew Olney
>
>>> On Saturday, March 19, 2011, Matthew Jonkman
>>> <jon...@emergingthreatspro.com> wrote:
>>>
>>>> Let this be VERY clear: I am not impuning the character or community spirit of Joel or Jason or any of the VRT guys. You're all great guys and I enjoy working with you all. But you work for the largest security vendor in the space who's only goal is to get more market share to jack up the share price while everyone prepares to cash out, or get yourselves bought by one of the big 5.
>>>
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Weir, Jason
times entertaining...
This is the crux of the problem - from an end users perspective..
I had what I thought was a FP on sid #1313.. I sent a note to the snort
sigs list - Nigel informed me that they had no such rule...
Hmmm, I thought the VRT was maintaining and distributing the GPL rules -
did a search and he was correct, no sid #1313
Some more looking - the sig came from ET - so I send a note to the et
sigs list.. Whoa, they don't maintain them either (I knew that duh)...
So the folks that maintain them wont and either will the folks that just
distribute them - come on guys!
If I choose to run multiple rule sets then duplicates are my problem -
why should ET or VRT care? You guys need to put out the most
comprehensive rule set you can. Who cares what the competition does..
Your end users surely don't!
This isn't about snort vs. suritica or ids vs. malware or not - ET and
VRT have different views of the world and again your end users don't
care!
I want a rule set that works and the GPL mess is broken... When I have
a question on a rule I need to know without a doubt where to go for help
- it's that simple...
Again my suggestion is do away with the GPL set completely - if that
means renaming and residing them (with or without reference to the old
rule) so be it... Make the rule set stand on its own and let me deal
with duplicates...
-J
> -----Original Message-----
> From: emerging-s...@emergingthreats.net
> [mailto:emerging-s...@emergingthreats.net] On Behalf
> Of Matthew Jonkman
> Sent: Monday, March 21, 2011 9:49 AM
> To: Martin Roesch
> Cc: wkit...@windstream.net;
> emergi...@emergingthreats.net; snort...@lists.sourceforge.net
> Subject: Re: [Emerging-Sigs] [Snort-users] GPL rules - who
> maintains them?Nobody?
>
>
> Cool, that's a very valid business model and strategy.
>
> Trying to bring this discussion back to GPL sids....
>
> Matt
>
_____________________________________________________________________________________________
Please visit www.nhrs.org to subscribe to NHRS email announcements and updates.
evil...@packetmail.net
Hash: SHA1
On 03/21/11 09:15, Matt Olney wrote:
> You've stepped FAR across a line, and an immediate
> apology is in order.
What? You just got done calling him a 'self-aggrandizing asshat', and in the
same mail, ask for an apology?
Why the hell are we, as security professionals, fighting with each other with
there's an ocean of evil out there.
This is stupid and we're playing a game of "touch the e-penis".
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNh15eAAoJENgimYXu6xOH9eAP/3mNKim3tXY6zoiPglyQrm6G
HdRqr3ndVeTQoHlZ+PMoW+3Nlstur53v47m0qdanp6jTgekSfmsFIPFdi2gujfX8
ALOmMzJjWhGtAV99R+3PNUjPfzkdTI6lOhuANiMblaZ35GWlX7JmpkoLSOXRE2sr
pWtopoq4bTjovmuI+6DGAnjktq/3hdJx0zXxlt7SQxpeS5DS5elr2pGS3GsTySTb
ISnYfePZGgB2UnCW6snVp60QfyQps0qnnsEZERQDFcWqZKmJAtmIS+0wT0NeEZHJ
IFADrJ8kd9m8yxwQNN2zhCShyUCX8MbIeFc5zh/azfrb52ybdFm3aYuRoFQmpmjd
dbK4QUym33djV7JXQI9P+E20n73mPX3/hBhcCwgG4tSghCsrxavE+QCSiXlERp4y
sSxSiwJjE6AmZ+FobBs1EEZFuQJk2xMDzZdFj2Ug3brfaRNoxu1viX2kkCC9vRsU
O3NyxXPMYHKx1x0qU1sr7fi3XkppLZDwTK0WwQOeKC2riQXopCk4FpWUKTjE6Av1
kCs9Xn5o+7TNdoFZ+zFKXmiM+vHZneBbRFvJXco1QNcnnySD4LbBnd1cr/HIeJv7
cv6bWI3XIuTlu37xkrJpxVSkmOpxJir3W9v5CTZ9hRBR23MSKQJ3v+Bb15sEzh1e
9pASd+7D8AYu0Gcfu/Xy
=VH2L
-----END PGP SIGNATURE-----
Matthew Jonkman
I prefer still not to re-sid them. Seems like a violation of the spirit of gpl in taking just the content and removing the reference to their history and origin. We'll still keep the license header though I suppose and reference their original sid range so folks can still search for relevant info.
I'd still prefer to keep them in sync somehow, if an option for that arises. Any other ideas?
Matt
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Matt Olney
I was "mentored", which occurred with appropriate speed and force. My
apologies to Mr. Jonkman for allowing my initial reaction to get the
better of me. I know better, and it did nothing to improve the
discourse on this list.
Matthew Olney
Person Who Was Wrong on the Internet
------------------------------------------------------------------------------
evil...@packetmail.net
Hash: SHA1
On 03/21/11 09:43, Joel Esler wrote:
> I'd like the maintainers of the ET GPL rules, if you insist on keeping the GPL
> rules, please fork them, re-sid them, and add a reference back to the original
> SID. Please do not duplicate the SIDS that are already assigned. That's the
> major point of this whole thread. To avoid this whole thread from occurring again.
This just doesn't make sense to fork them. If the changes are good and
rational, either made by VRT or ET, each party should discuss and updating
according.
It's really stupid to fork them to not add any new functionality -- what is
being done is that accuracy or detection is improved, not that the spirit of the
old signature as gone and a true fork is required.
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNh2VOAAoJENgimYXu6xOH0YwQAJtoqzrhhkPNOR3ADMyl0yUh
4zsCF38Fll6C89oGfNRby5C/kVdIUzFtPGN7E2+cGktCo+sUCiqBYHf2YSipww/J
aEPdM3oAkxmzVhorit9HyhLqUviLDmyVmZMPesp7je1HCxbCWCRFKUroO93n+tuP
ZuCUkF7KoXDmGxdRH3jNFCrScy/kuXvskRmGLSdExXs+hY6LdpWr3Vs9nveOw8xZ
IXvrhJiWnw6wBR1eYZ6Oje+p3j0r9+zvZ535e2QNppfBW3J8dM+Qazqh2dbnAjMs
eqzewZNzcBEVB1NUH4gBlCB441XMG3QlMCTiiLi3FKOJYfQzYVvs+TQD0OK+bple
ooI5JfYSi/P66yW/HlqQ55P3pR93dGb1VJwb5DgkM6Iwf/Gol4JneA10vAADI2gJ
FPuIVzExtueXRqqLSkkBunT1CLcpTCYg9e7kBAUOTjLBKeEjsg4Pfc1lF8Cofpvt
FiQoJNj3ZkVJRafwGXvNtF4yYY4nWXjHHRIHwd4zImA22UXyKMpLzwIByLKJckod
WwifJGFqW1IrMDXtnAjy424iQLHesp78Cyy4pac07Z21oL1jffxBwhQ8QJPZq4IS
oRxu0R34I3eIulJKCRDuvBu/pcWWJrcH+9hi0ZLZJDcPBJDo5F7GGusGxjsOyCfd
gL8LwuqJn6AS0P353QZL
=hgVs
Matthew Jonkman
Businesses of course are value driven. But that doesn't result in the work ethic of the employees being the same. It wasn't fair of me to make that connection. I apologize as well.
Lets get back to solving the sid issues.
Matt
On Mar 21, 2011, at 10:38 AM, Matt Olney wrote:
> Yep, you're right. I was totally out of line and even knew it before
> I was "mentored", which occurred with appropriate speed and force. My
> apologies to Mr. Jonkman for allowing my initial reaction to get the
> better of me. I know better, and it did nothing to improve the
> discourse on this list.
>
> Matthew Olney
> Person Who Was Wrong on the Internet
>
> On Mon, Mar 21, 2011 at 10:19 AM, evil...@packetmail.net
> <evil...@packetmail.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/21/11 09:15, Matt Olney wrote:
>>> You've stepped FAR across a line, and an immediate
>>> apology is in order.
>>
>> What? You just got done calling him a 'self-aggrandizing asshat', and in the
>> same mail, ask for an apology?
>>
>> Why the hell are we, as security professionals, fighting with each other with
>> there's an ocean of evil out there.
>>
>> This is stupid and we're playing a game of "touch the e-penis".
>>
>> - --
>> It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
>> strong.
>>
>> - -evilghost
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iQIcBAEBAgAGBQJNh15eAAoJENgimYXu6xOH9eAP/3mNKim3tXY6zoiPglyQrm6G
>> HdRqr3ndVeTQoHlZ+PMoW+3Nlstur53v47m0qdanp6jTgekSfmsFIPFdi2gujfX8
>> ALOmMzJjWhGtAV99R+3PNUjPfzkdTI6lOhuANiMblaZ35GWlX7JmpkoLSOXRE2sr
>> pWtopoq4bTjovmuI+6DGAnjktq/3hdJx0zXxlt7SQxpeS5DS5elr2pGS3GsTySTb
>> ISnYfePZGgB2UnCW6snVp60QfyQps0qnnsEZERQDFcWqZKmJAtmIS+0wT0NeEZHJ
>> IFADrJ8kd9m8yxwQNN2zhCShyUCX8MbIeFc5zh/azfrb52ybdFm3aYuRoFQmpmjd
>> dbK4QUym33djV7JXQI9P+E20n73mPX3/hBhcCwgG4tSghCsrxavE+QCSiXlERp4y
>> sSxSiwJjE6AmZ+FobBs1EEZFuQJk2xMDzZdFj2Ug3brfaRNoxu1viX2kkCC9vRsU
>> O3NyxXPMYHKx1x0qU1sr7fi3XkppLZDwTK0WwQOeKC2riQXopCk4FpWUKTjE6Av1
>> kCs9Xn5o+7TNdoFZ+zFKXmiM+vHZneBbRFvJXco1QNcnnySD4LbBnd1cr/HIeJv7
>> cv6bWI3XIuTlu37xkrJpxVSkmOpxJir3W9v5CTZ9hRBR23MSKQJ3v+Bb15sEzh1e
>> 9pASd+7D8AYu0Gcfu/Xy
>> =VH2L
>> -----END PGP SIGNATURE-----
>>
>>
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Martin Roesch
>From my viewpoint we have a few pretty simple options:
1) ET forks the GPL rules and maintains/distributes their own set. In
this case they should take new SIDs because we don't want to have
inconsistency in what is being detected for a given SID number. This
would cause havoc in any automated event processing backend and should
be avoided at all costs.
2) ET maintains a patch set against the GPL rules that people can
download/apply as needed. As part of this patch set they should
probably be renumbered unless the patch is accepted into the canonical
set maintained by Sourcefire. We do something similar in our
commercial product when a user elects to modify an existing (VRT)
rule. We renumber the rule into "userland" SID-space and the editing
continues from there. This is done to avoid disrupting backend
processing both in our and other's event processing systems.
3) ET distributes the unmodified GPL rules. Apart from
"one-stop-shopping" I don't see a lot of need for this.
4) ET develops their own rules that cover detection of the same things
that the GPL detects in their own SID-space. Apart from the
unnecessary duplication of effort and inefficiency in the detection
engine this would work.
Am I missing a case here?
Marty
On Mon, Mar 21, 2011 at 10:43 AM, Joel Esler <jes...@sourcefire.com> wrote:
> Okay --
> I've say back some of this discussion to see how it would pan out. But I
> feel as if this has gone on long enough without input, not saying I'm
> cutting it short, but.... Let me sum up everything as I see it, and
> hopefully we can fix the whole issue.
>
> I haven't diff'ed your version of the gpl rules to ours, I'll try and make
> time to do that today if I can -- and I haven't diffed our gpl rules from
> 2005 to now (3464 and below), but I suspect they haven't changed much maybe
> some references and what not, but I'd like to see what else.
> I have a couple ideas that I have discussed with Sourcefire internally, and
> I'm not going to talk about those until they come out. I don't want to say
> "here's my idea" and then have someone print it out and staple it to a wall.
> (evilghost -- ;).
> I'd like the maintainers of the ET GPL rules to please send me any changes
> that you have made to the rules that we could incorporate, as that has not
> been done yet, and it should be.
> I'd like the maintainers of the ET GPL rules, if you insist on keeping the
> GPL rules, please fork them, re-sid them, and add a reference back to the
> original SID. Please do not duplicate the SIDS that are already assigned.
> That's the major point of this whole thread. To avoid this whole thread
> from occurring again.
> If we are going to coexist, (ET and VRT) then this is the way it must be.
> We are a community. We are acting like one, we will have our fights and
> our disagreements, that's fine. But let's make them constructive.
>
> On a personal note, I've tried to reach out heavily to you Matt both on list
> and privately to try and unify the communities, you go your way with PRO
> sigs and we go our way with PRO sigs. But meet in the middle somewhere.
> I've received zero push back from Sourcefire on this, and I've received
> nothing but "I don't believe you", "It hasn't worked before", etc from your
> side.
> I do feel a bit insulted that you'd insult me or Jason's integrity or
> "community spirit" (as that's my job), and even more insulted that anyone
> would insult the VRT. They are a very hardworking group of individuals, and
> no one understands what goes on in that group if you aren't inside. On
> purpose. Are we going to open that kimono a bit? I hope so.
> I'm not asking for an apology, this is my job. To have these discussions
> and come up with a solution that is best for the community. I have a couple
> ideas that may or may not work, and that's fine either way. If they don't
> work, then we'll keep going the way we have been going. If they do work,
> then we'll have a closer community. But please don't say that I have no
> community spirit or aren't working to unify it.
> Would I like to have a healthy working relationship between ET, the VRT, and
> the community? Yes.
> I do not presume to speak for VRT, but I am sure a healthy community is also
> in their interests as well. Do I think we have a dysfunctional marriage
> right now? Yes.
> Do I think we can fix it? Yes.
>
> Thanks,
> Joel
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Snort-users mailing list
> Snort...@lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
------------------------------------------------------------------------------
evil...@packetmail.net
Hash: SHA1
On 03/21/11 10:26, Martin Roesch wrote:
> Am I missing a case here?
Yeah, this is an obtuse approach. There are two ET rule packs, Open and
Open-NoGPL. They are just that, users of VRT who get the GPL rules would use
Open-NoGPL. ET-only folks would use Open, which would include the GPL rules.
I don't understand the point behind re-SID and duplication, patching, etc. If
the changes made to a "ET" GPL rule make sense, why wouldn't VRT want to
consider it for inclusion/update? Vice versa.
There's no point to fork when adjustments are made to enhance detection, improve
performance, or reduce false positives. Why wouldn't VRT want an improved rule?
Do you really suggest we ask dual-subscribers (VRT, and ET) to run two sets of
the same rule, one stagnated and legacy, the other an updated re-SID of the same
rule?
- --
It has been said that "hate" is a powerful emotion, perhaps that's why I'm so
strong.
- -evilghost
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJNh3INAAoJENgimYXu6xOHCSgQAIlOmfVumbIkK7QjtZy8pc03
7Es3/PMGHxSGxtWEQQNjmyVT+GLUtigawHow665UjHWLTTq5c4GRgZRx0aP6qFTL
36m62vMu/7s0/btPtFXgfxBF0jTkV5GEpu2ogqRA5jR6k9AqzxubY2VehZUb7wCx
APE8vw3GkC2XQ2qjii5yZC7dQU9KmbdjnrUL1uURFW5o8Xn7toXlT/DzClUod08g
A3a6d/Ot+nzF3BlaZIPYc+tO/a03PFAD37jrBVR6tRpMFHiT3DLEpuZ873lBDvxp
2w3+kHbYdUYew7aCkcJBuVROLStQdcrpxxxbAqZIdzDVOptLKdRGS8aYkBwh5NAu
Em2WxiUVgqo2lspynXL//M2jigJtPhMoJXnLDRB7WkVuWRsftAmqWMd3251yVyy7
mr7p4JTJmxRXLDCoSeDc4HlKW79sD7qXoC9Kqd/fHm6T1KtcRHXFQmC1j1RW2ewt
/6AcLpLoUjnLNfu4zktAtV4+4W6xa7VwKeUazwZZY6gQ0FjeiHSVHQdp4xWsQhUR
cwqLIKiSdU7nZZB2lkHtDIwub6Hiyh7ulvY3qv8W4Y47PRM0bbjcpVctt8TK9rYH
uzMiChlHBgTjLvSo42I1MXEmpnf4P1AqBRVlkWkn0qIKXViIBg1Q6eKLW1DpbRgO
Ah28muAgarxxxO8fSN88
=SEjV
-----END PGP SIGNATURE-----
Weir, Jason
They retired it - but ET still has at least 6 versions of it.
Say I'm a VRT subscriber, so I get their GPL rules - I also wanna run
the ET rules so I get their Open-NoGPL rules.. I don't get #1313 - what
else don't I get?
See the problem here - ET is already maintaining those rules and by
porting them to Suricata they have already forked them..
You can't push a Suricata only modification back up the chain to VRT.
The rule sets need to stand on their own... And that means different
sid ranges across the board...
-J
> -----Original Message-----
> From: emerging-s...@emergingthreats.net
> [mailto:emerging-s...@emergingthreats.net] On Behalf
> Of evil...@packetmail.net
> Sent: Monday, March 21, 2011 11:43 AM
> To: Martin Roesch
> Cc: emergi...@emergingthreats.net;
> snort...@lists.sourceforge.net; Matthew Jonkman
> Subject: Re: [Emerging-Sigs] [Snort-users] GPL rules - who
> maintains them?Nobody?
>
> On 03/21/11 10:26, Martin Roesch wrote:
> > Am I missing a case here?
>
> Yeah, this is an obtuse approach. There are two ET rule
> packs, Open and
> Open-NoGPL. They are just that, users of VRT who get the GPL
> rules would use
> Open-NoGPL. ET-only folks would use Open, which would
> include the GPL rules.
>
> I don't understand the point behind re-SID and duplication,
> patching, etc. If
> the changes made to a "ET" GPL rule make sense, why wouldn't
> VRT want to
> consider it for inclusion/update? Vice versa.
>
> There's no point to fork when adjustments are made to enhance
> detection, improve
> performance, or reduce false positives. Why wouldn't VRT
> want an improved rule?
>
> Do you really suggest we ask dual-subscribers (VRT, and ET)
> to run two sets of
> the same rule, one stagnated and legacy, the other an updated
> re-SID of the same
> rule?
>
> - -evilghost
_____________________________________________________________________________________________
Please visit www.nhrs.org to subscribe to NHRS email announcements and updates.
Martin Holste
as a new rule and the old one is disabled from now on until the GPL
set has been metamorphosized into either VRT/ET normal rule sets.
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>
------------------------------------------------------------------------------
Martin Roesch
On Mon, Mar 21, 2011 at 11:43 AM, evil...@packetmail.net
<evil...@packetmail.net> wrote:
> On 03/21/11 10:26, Martin Roesch wrote:
>> Am I missing a case here?
>
> Yeah, this is an obtuse approach. There are two ET rule packs, Open and
> Open-NoGPL. They are just that, users of VRT who get the GPL rules would use
> Open-NoGPL. ET-only folks would use Open, which would include the GPL rules.
>
> I don't understand the point behind re-SID and duplication, patching, etc. If
> the changes made to a "ET" GPL rule make sense, why wouldn't VRT want to
> consider it for inclusion/update? Vice versa.
Basically the SIDs were created for machine processing as much as they
exist for people, we don't want to have one SID mean two different
things and it's easy to change SIDs. There are SIEM and other event
processing systems that rely completely on the SID numbers having a
discrete meaning so that any correlation they might do is correct and
consistent. I'm not saying that they *will* become inconsistent down
the road but they *might* so just trying to think ahead it seems
easiest to me to just have a separate SID-space if they are to be,
effectively, forked.
> There's no point to fork when adjustments are made to enhance detection, improve
> performance, or reduce false positives. Why wouldn't VRT want an improved rule?
I suppose that depends on your definition of "improved". :) Or maybe
I should say not all rules are improved equally or something. Anyway,
the issue on accepting a patch that improves the efficacy of the rule
at the cost of ruinous impact on performance (as an example) could be
one case where VRT wouldn't accept a patch. I'm sure there are other
cases where similar situations could arise.
> Do you really suggest we ask dual-subscribers (VRT, and ET) to run two sets of
> the same rule, one stagnated and legacy, the other an updated re-SID of the same
> rule?
No, not really. The ideal outcome from my standpoint is to have one
rule to detect a given attack and the canonical GPL set to remain the
canonical set. I think case 2 that I described in my last post
reflects the "best" way to achieve that.
Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org
------------------------------------------------------------------------------
Matthew Jonkman
So staying in sync will be an issue if VRT is the master record of the rules. So perhaps our only option is to completely fork. But then I still don't feel we need to re-sid since the original intent will still be the same for each signature. So the references will still apply, and I don't think we'll have collision issues as we distribute rulesets with and without.
There are issues going either way I suppose. Will have to think it over a bit.
Matt
On Mar 21, 2011, at 11:26 AM, Martin Roesch wrote:
> Ok, just my $0.02 here.
>
>> From my viewpoint we have a few pretty simple options:
>
> 1) ET forks the GPL rules and maintains/distributes their own set. In
> this case they should take new SIDs because we don't want to have
> inconsistency in what is being detected for a given SID number. This
> would cause havoc in any automated event processing backend and should
> be avoided at all costs.
>
> 2) ET maintains a patch set against the GPL rules that people can
> download/apply as needed. As part of this patch set they should
> probably be renumbered unless the patch is accepted into the canonical
> set maintained by Sourcefire. We do something similar in our
> commercial product when a user elects to modify an existing (VRT)
> rule. We renumber the rule into "userland" SID-space and the editing
> continues from there. This is done to avoid disrupting backend
> processing both in our and other's event processing systems.
>
> 3) ET distributes the unmodified GPL rules. Apart from
> "one-stop-shopping" I don't see a lot of need for this.
>
> 4) ET develops their own rules that cover detection of the same things
> that the GPL detects in their own SID-space. Apart from the
> unnecessary duplication of effort and inefficiency in the detection
> engine this would work.
>
> Am I missing a case here?
>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Snort-users mailing list
>> Snort...@lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe:
>> https://lists.sourceforge.net/lists/listinfo/snort-users
>> Snort-users list archive:
>> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>>
>
>
>
> --
> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
> Sourcefire - Security for the Real World - http://www.sourcefire.com
> Snort: Open Source IDP - http://www.snort.org
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Nigel Houghton
> That makes sense. That's basically Marty's #2 point. I'd say the
> porn.rules files can be re-sid'ed (referencing Jason's problem) as
> VRT has dropped those completely, as well as other improved rules can
> be re-sid.
Like I said earlier, there is no need to re-SID these rules. We won't
be re-using any of the SIDs from those rules. Any changes to them can
be better tracked by incrementing the rev number on them and leaving
the SIDs themselves well alone.
--
Nigel Houghton
Head Mentalist
SF VRT Department of Intelligence Excellence
http://vrt-blog.snort.org/ && http://labs.snort.org/
Nigel Houghton
> On Mon, Mar 21, 2011 at 12:25 PM, Nigel Houghton
> <nhou...@sourcefire.com> wrote:
>> On Mon, 21 Mar 2011 12:10:17 -0400, Joel Esler wrote:
>>> That makes sense. That's basically Marty's #2 point. I'd say the
>>> porn.rules files can be re-sid'ed (referencing Jason's problem) as
>>> VRT has dropped those completely, as well as other improved rules can
>>> be re-sid.
>>
>> Like I said earlier, there is no need to re-SID these rules. We won't
>> be re-using any of the SIDs from those rules. Any changes to them can
>> be better tracked by incrementing the rev number on them and leaving
>> the SIDs themselves well alone.
>>
>
Changes to other GPL rules should be handled in a similar manner. Keep
the SID bump the rev. We will always modify a rule if there is a change
needed. Reasons for the change could be:
1. Improvement in detection functionality provided by new
functionality in Snort. In this instance, the rule will be modified for
that new version of Snort. Rules for older versions remain untouched
and just like it is right now, the rules are shipped on a per-Snort
version basis (so the rules still work for a particular version of
Snort). This means that rules for older versions do not get a revision
bump.
2. False positive/negative content match change or addition of content
match to improve detection. In this instance the rule gets modified for
all currently supported versions of Snort and the rev for each rule is
bumped. For folks who are running non-supported versions, this
modification should be done by whoever wants to maintain the rules for
those older sets and the rev bumped accordingly. Since rules for
specific versions of Snort should be shipped in separate packages, this
should not impose a problem.
3. A reference change or addition. Much like #2, the rev gets bumped
for all versions of the rule for all versions of Snort.
Any reported instances of false positive/negative cases should be
reported to the VRT in the usual manner. Suggestions for improvement
are certainly welcomed and will be handled appropriately. i.e. consider
it a case that fits into #2.
If a user makes changes to a rule for their particular environment, the
rule should be converted to a local rule and given a local SID. Then
the user can disable the original rule and make changes as appropriate
should the original rule be changed for some reason. This does of
course mean that the user should implement a tracking mechanism for
their local rules and the original rules they are based off.
I do not see a case for copying rules and re-numbering for distribution
to the general populace. This just makes the job of managing rules
needlessly more complex for the end user. FWIW, we are more than
capable of incorporating changes to rules and re-distributing them in a
very short space of time if the need arises (as in, we can do this in a
matter of minutes if no QA, other than running the rule over test pcaps
for that vulnerability is required or full regression testing is not
needed). However, we are not inclined to issue rule changes at the drop
of a hat and then have to re-issue the rules shortly thereafter because
the change either did not work or introduced a false positive/negative
case. If anyone has suggested rule changes, our advice is to test your
change thoroughly in your environment first (i.e. go the local SID
route) to see if anything untoward or unexpected occurs.
Randal T. Rioux
<evil...@packetmail.net> wrote:
<snip>
> This is stupid and we're playing a game of "touch the e-penis".
Eww.
http://ihasahotdog.files.wordpress.com/2009/11/funny-dog-pictures-using-word.jpg
Randy
Nigel Houghton
> Agree, that's our standard practice and suggestion. The issue comes
> up as Emerging Threats has taken the GPL sigs (3464 and below) and
> has included them in their ruleset and made modifications.
>
> I've made the suggestion that ET please submit these changes back to
> the VRT and if appropriate, we include the updates in the official
> set.
>
> Basically, ET is using the same sids that we are.
>
> J
>
> On Mon, Mar 21, 2011 at 1:26 PM, Nigel Houghton
I see. In that case, ET should act as an end-user, copy the rule to
another file, give it a new SID and leave the original alone and
disabled in the rule file. If the change is appropriate, send the
suggested modification along to us and we will handle it. In the case
of the modification being needed for a currently supported version of
Snort, the rule will get the update for each version (see #2). In the
case of older, non-supported versions, the rule can remain where it is
and any modification distributed for that version of Snort as the
maintainer sees fit. Since we do not maintain rules for outdated
versions of Snort, there will be no SID conflict.
This is a pretty simple process that merely relies on feedback to
incorporate suitable changes with minimal impact on the end-user.
--
Nigel Houghton
Head Mentalist
SF VRT Department of Intelligence Excellence
http://vrt-blog.snort.org/ && http://labs.snort.org/
------------------------------------------------------------------------------
Jason Wallace
Well stated, Mike. That is, point-for-point, exactly my opinion as well.
Thx,
Wally
On Mon, Mar 21, 2011 at 2:18 PM, Mike Lococo <mike....@nyu.edu> wrote:
> Matt,
>
>> So staying in sync will be an issue if VRT is the master record of
>> the rules. So perhaps our only option is to completely fork. But then
>> I still don't feel we need to re-sid since the original intent will
>> still be the same for each signature. So the references will still
>> apply, and I don't think we'll have collision issues as we distribute
>> rulesets with and without.
>
> This proposal appears to be an extension and formalization of what's
> been happening already. Please recall that this thread was started
> because of the problems this solution is causing today in the ET
> community (from my previous message):
>
>>> 1- Loss of rule-selection control by the snort-admin. In a
>>> sid-overlap world, it's not possible to run VRT + ET with the
>>> ET-GPL variants. It's also not possible to pick-and-choose
>>> individual GPL rules between the projects or test both in
>>> parallel. Re-sid'ing puts rule-selection control in the hands of
>>> the snort-admin where it belongs, not in the hands of the rules-
>>> projects that have little incentive to cooperate on producing a
>>> compatible combined-ruleset.
>>> 2- Confusion about who to submit patches to, especially as the
>>> rulesets diverge (which they are already doing).
>>> 3- Snort-admins now have a confusing choice to make as to whether to
>>> download the gpl or no-gpl versions of ET/ETPro. The choice
>>> can't be avoided or delayed, and there's no documentation at
>>> rules.emergingthreats.net that helps inform you how to make the
>>> decision. In a re-sid'ed world, the GPL choice becomes an optional
>>> performance-optimization or rule-tuning activity, not a blocker to
>>> acquiring your first ruleset.
>>> 4- Pulled pork required patching to allow duplicate sids, which means
>>> that admins are now much more likely to ignore real/broken duplicate
>>> sid-instances in their setups resulting in missed-detections and
>>> unnecessary troubleshooting.
>
> The arguments against re-sidding appear to be:
>
> a- "It's against the spirit of the GPL." The purpose of the GPL is
> to ensure Freedoms are preserved up-and-down the consumption
> chain, not to enforce cooperation between any two specific
> groups or prevent snort-rules from changing sids. Forking when
> projects disagree is well-within the spirit of the GPL, and
> engineering the fork to minimize cross-project dependencies
> (eg rule-sync of duplicated sids) ensures that the projects
> can operate without stepping on each other's feet and causing bad
> blood.
> b- "Duplicated rule-functionality will cause poor performance."
> This ship has definitively sailed, there is already an *ENORMOUS*
> amount of rule duplication between the ET and VRT, and even more
> between ETPro and VRT. The amount of redundancy *IS* going to
> increase as ETPro expands. The "nogpl" download-variants
> do not eliminate redundancy, and such a scheme cannot scale to
> do so. Users who choose to run both rulesets either have the
> sophistication to pick-and-choose, or want multi-vendor
> redundancy in some areas as a sanity-check. See (1).
> c- "Re-sidding is unnecessary." It's only unnecessary if the
> projects can function cooperatively to stay in sync. It could
> not be more clear that the projects are NOT doing so right
> now. See (2) and every message in this thread.
> d- "You don't need to run both rulesets anyway." This decision
> should be in the hands of the on-site admins, the rules-projects
> should not force them to abandon one of the rulesets. See (1).
> e- "Nogpl variants solve this problem." They don't, you can't pick
> and choose on a sid-by-sid basis, and you can't use the
> "improved" ET-GPL variants if you run any VRT rules at all.
> See (1).
>
> Please fork and re-sid, it's better for your community and for your
> customers.
>
> Best Regards,
> Mike Lococo
> _______________________________________________
> Emerging-sigs mailing list
> Emergi...@emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>
------------------------------------------------------------------------------
Matthew Jonkman
That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
If folks are happy with not being able to easily combine with VRT then we can go that direction.
Matt
----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
Weir, Jason
> From: emerging-s...@emergingthreats.net
> [mailto:emerging-s...@emergingthreats.net] On Behalf
> Of Matthew Jonkman
> Sent: Monday, March 21, 2011 3:23 PM
> To: Jason Wallace
> Cc: emergi...@emergingthreats.net; Snort-Users; Mike Lococo
> Subject: Re: [Emerging-Sigs] [Snort-users] GPL rules - who
> maintains them?Nobody?
>
>
> open ruleset with VRT.
I'd say let us users worry about that - plenty of overlap already to
deal with.. Snort (any IDS) takes lots of care and feeding, I think
we're use to that - especially if we choose to run competing rule
sets...
>
> That'd be easiest for us long term, but doesn't make it easy
> for us to do the no-gpl rulesets.
>
> If folks are happy with not being able to easily combine with
> VRT then we can go that direction.
>
> Matt
I'd also say do what's best long term for the ruleset.. Remember
good\easy\fast pick 2...
During the fork, I'd rename and drop the GPL tag so those with
pulledpork can do a pcre:GPL and automatically disable them on the VRT
side of things.
-J
_____________________________________________________________________________________________
Please visit www.nhrs.org to subscribe to NHRS email announcements and updates.
Jason Wallace
could pick and chose between the ET distributed GPL rules and the VRT
distributed rules. That is not possible today, because they use the
same SID and most rule management tools are SID driven so you can't
enable/disable a SID without SID duplication. The no-gpl model
requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
ET set. We can't chose to use one gpl rule from the VRT and another
gpl rule from ET, because the two can't exist at the same time.
Like Mike said, the whole idea of coverage duplication being an issue
is a completely invalid, because that is already a nightmare now.
There is no valid reason to not fork and re-SID. That act will finally
put and end to this problem and let US, the end user, make our own
desiccation about where we get rules from without being forced down
some predetermined path.
Thx,
Wally
On Mon, Mar 21, 2011 at 3:23 PM, Matthew Jonkman
<jon...@emergingthreatspro.com> wrote:
> But fork and re-sid makes it tough for folks to combine the open ruleset with VRT.
>
> That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
>
> If folks are happy with not being able to easily combine with VRT then we can go that direction.
>
> Matt
>
>
------------------------------------------------------------------------------
Weir, Jason
BTW is it big word day? First we get aggrandizing and now desiccation -
I've had to google too many words today, although I think that last one
was over judicious use of the spell checker...
-J
> -----Original Message-----
> From: emerging-s...@emergingthreats.net
> [mailto:emerging-s...@emergingthreats.net] On Behalf
> Of Jason Wallace
> Sent: Monday, March 21, 2011 3:47 PM
> To: Matthew Jonkman
> Cc: emergi...@emergingthreats.net; Snort-Users
> Subject: Re: [Emerging-Sigs] [Snort-users] GPL rules - who
> maintains them?Nobody?
>
>
> No, it makes it easier to combine them, in my opinion, because then we
> could pick and chose between the ET distributed GPL rules and the VRT
> distributed rules. That is not possible today, because they use the
> same SID and most rule management tools are SID driven so you can't
> enable/disable a SID without SID duplication. The no-gpl model
> requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
> ET set. We can't chose to use one gpl rule from the VRT and another
> gpl rule from ET, because the two can't exist at the same time.
>
> Like Mike said, the whole idea of coverage duplication being an issue
> is a completely invalid, because that is already a nightmare now.
>
> There is no valid reason to not fork and re-SID. That act will finally
> put and end to this problem and let US, the end user, make our own
> desiccation about where we get rules from without being forced down
> some predetermined path.
>
> Thx,
> Wally
_____________________________________________________________________________________________
Please visit www.nhrs.org to subscribe to NHRS email announcements and updates.
Jason Wallace
On Mon, Mar 21, 2011 at 3:58 PM, Matthew Jonkman
<jon...@emergingthreatspro.com> wrote:
> If we re-sid though it'll be very difficult to manage them or identify the duplicated rules if you pull in the vrt rules as well.
>
> We won't have them all in one file, or likely with a unique tag in the title. They'll be distributed as they are now in their respective categories.
>
> If we plan well and bring some extra manpower online for the re-sid we could conceivably get them into a contiguous sid range to help with automated enabling/disabling. That'll be a challenge though.
>
> Matt
>
> On Mar 21, 2011, at 3:46 PM, Jason Wallace wrote:
>
>> No, it makes it easier to combine them, in my opinion, because then we
>> could pick and chose between the ET distributed GPL rules and the VRT
>> distributed rules. That is not possible today, because they use the
>> same SID and most rule management tools are SID driven so you can't
>> enable/disable a SID without SID duplication. The no-gpl model
>> requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
>> ET set. We can't chose to use one gpl rule from the VRT and another
>> gpl rule from ET, because the two can't exist at the same time.
>>
>> Like Mike said, the whole idea of coverage duplication being an issue
>> is a completely invalid, because that is already a nightmare now.
>>
>> There is no valid reason to not fork and re-SID. That act will finally
>> put and end to this problem and let US, the end user, make our own
>> desiccation about where we get rules from without being forced down
>> some predetermined path.
>>
>> Thx,
>> Wally
>>
------------------------------------------------------------------------------
Jeff Kell
> No, it makes it easier to combine them, in my opinion, because then we
> could pick and chose between the ET distributed GPL rules and the VRT
> distributed rules. That is not possible today, because they use the
> same SID and most rule management tools are SID driven so you can't
> enable/disable a SID without SID duplication. The no-gpl model
> requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
> ET set. We can't chose to use one gpl rule from the VRT and another
> gpl rule from ET, because the two can't exist at the same time.
Well, in the old oinkmaster days + snort.conf, you just include the
rules you wanted.
With pulledpork and the "big blob" rules, the SID independence is a
bigger factor.
Jeff
------------------------------------------------------------------------------
Enable your software for Intel® Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
Jason Brvenik
On Mon, Mar 21, 2011 at 4:05 PM, Jason Wallace
<jason.r...@gmail.com> wrote:
> What is the issue with tagging them in the msg?
>
> On Mon, Mar 21, 2011 at 3:58 PM, Matthew Jonkman
> <jon...@emergingthreatspro.com> wrote:
>> If we re-sid though it'll be very difficult to manage them or identify the duplicated rules if you pull in the vrt rules as well.
>>
>> We won't have them all in one file, or likely with a unique tag in the title. They'll be distributed as they are now in their respective categories.
>>
>> If we plan well and bring some extra manpower online for the re-sid we could conceivably get them into a contiguous sid range to help with automated enabling/disabling. That'll be a challenge though.
>>
>> Matt
>>
>> On Mar 21, 2011, at 3:46 PM, Jason Wallace wrote:
>>
>>> No, it makes it easier to combine them, in my opinion, because then we
>>> could pick and chose between the ET distributed GPL rules and the VRT
>>> distributed rules. That is not possible today, because they use the
>>> same SID and most rule management tools are SID driven so you can't
>>> enable/disable a SID without SID duplication. The no-gpl model
>>> requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
>>> ET set. We can't chose to use one gpl rule from the VRT and another
>>> gpl rule from ET, because the two can't exist at the same time.
>>>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
waldo kitty
> I'm not saying we don't want an improved rule if the changes improve the rule.
> I'm saying that the changes have not been submitted back to us.
i think one of the most basic tenets of the "problem at hand" is "who maintains
the GPL rules set?" a "cross" question would be "who started them and originally
maintained them?"
another question is "who has the desire and resources to handle maintaining the
GPL rules?"
surely the resources and traffic are not all that much... not in the simplest of
implementations...
waldo kitty
> I see. In that case, ET should act as an end-user, copy the rule to
> another file, give it a new SID and leave the original alone and
> disabled in the rule file. If the change is appropriate, send the
> suggested modification along to us and we will handle it.
and herein is the crux of the apparent problem... why "you" (inclusive and
apparently meaning VRT)... why not ET? especially since they are, at least,
willing to provide the rules in a format that older snorts can handle and
properly detect the traffic in question??
who owned them to start with? who maintained them to start with? why are they
now as they are?
waldo kitty
> But fork and re-sid makes it tough for folks to combine the open ruleset with VRT.
>
> That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
>
> If folks are happy with not being able to easily combine with VRT then we can go that direction.
please see my earlier response RE: everyone carry the GPL in a special rules set
file so that those who want to include it in their operations can enable it in
their configs and everyone else can (leave them) disable(d) in their's...
Joel Esler
> On 3/21/2011 11:47, Joel Esler wrote:
>> I'm not saying we don't want an improved rule if the changes improve the rule.
>> I'm saying that the changes have not been submitted back to us.
>
> i think one of the most basic tenets of the "problem at hand" is "who maintains the GPL rules set?" a "cross" question would be "who started them and originally maintained them?"
>
> another question is "who has the desire and resources to handle maintaining the GPL rules?"
We already do. They are part of the VRT ruleset, always have been.
--
Joel Esler
jesler () sourcefire.com
http://blog.snort.org && http://blog.clamav.net
Twitter: @snort
Joel Esler
> On 3/21/2011 14:00, Nigel Houghton wrote:
>> I see. In that case, ET should act as an end-user, copy the rule to
>> another file, give it a new SID and leave the original alone and
>> disabled in the rule file. If the change is appropriate, send the
>> suggested modification along to us and we will handle it.
>
> and herein is the crux of the apparent problem... why "you" (inclusive and apparently meaning VRT)... why not ET? especially since they are, at least, willing to provide the rules in a format that older snorts can handle and properly detect the traffic in question??
The easiest way to test this would be to take the GPL ruleset from now, and start it up in an old version of Snort 2.8.4 or whatever. See if it starts. If it does, then the whole point is moot.
> who owned them to start with? who maintained them to start with? why are they now as they are?
Sourcefire/VRT/Snort.org. Why were they forked in the first place? I don't know. That's a good question.
Nigel Houghton
> On 3/21/2011 14:00, Nigel Houghton wrote:
>> I see. In that case, ET should act as an end-user, copy the rule to
>> another file, give it a new SID and leave the original alone and
>> disabled in the rule file. If the change is appropriate, send the
>> suggested modification along to us and we will handle it.
>
> and herein is the crux of the apparent problem... why "you"
> (inclusive and apparently meaning VRT)... why not ET? especially
> since they are, at least, willing to provide the rules in a format
> that older snorts can handle and properly detect the traffic in
> question??
>
> are they now as they are?
The original distribution point is snort.org, the original distributors
are the Snort team and after it's inception, Sourcefire (in fact, when
Sourcefire started the rule sids hadn't yet gotten much past 1000, and
most of those are now deleted). IIRC, when I started at Sourcefire in
2002, we were somewhere around the 1300 mark. So, if it's original
distributor you want, then it's Sourcefire, that's "why not ET". You
also omitted further relevant information from my email that is:
"In the case of the modification being needed for a currently supported
version of Snort, the rule will get the update for each version (see
#2). In the case of older, non-supported versions, the rule can remain
where it is and any modification distributed for that version of Snort
as the maintainer sees fit. Since we do not maintain rules for outdated
versions of Snort, there will be no SID conflict.
This is a pretty simple process that merely relies on feedback to
incorporate suitable changes with minimal impact on the end-user."
And for your convenience, here is the #2 in question again:
"2. False positive/negative content match change or addition of content
match to improve detection. In this instance the rule gets modified for
all currently supported versions of Snort and the rev for each rule is
bumped. For folks who are running non-supported versions, this
modification should be done by whoever wants to maintain the rules for
those older sets and the rev bumped accordingly. Since rules for
specific versions of Snort should be shipped in separate packages, this
should not impose a problem."
--
Nigel Houghton
Head Mentalist
SF VRT Department of Intelligence Excellence
http://vrt-blog.snort.org/ && http://labs.snort.org/
------------------------------------------------------------------------------
Philip Neukom
from all the discussions. Sometime I get a good laugh too!
Being a perpetual newbie at the complete IDS/IPS area and a business guy
to boot, I was wondering why the suggestion to create a community based
CVS for the GPL rules wasn't interesting or at least discussed by
anyone. I don't know if it was ignored out of hand or got lost in the
flaming back and forth. I may have missed a comment as I'm on digest mode.
I understand that there are various interest groups and that is typical
of all projects. But I have to assume that everyone wants a complete
and optimized list. Since it is GPL I also presume that most people
want to share and help each other.
So is it my naïveté that having a central CVS set-up as many other
open-source projects with a commit structure etc. is a stupid idea?
Can't this one list have a commit structure/organization similar to
other projects?
Nuke.
Matthew Jonkman
We won't have them all in one file, or likely with a unique tag in the title. They'll be distributed as they are now in their respective categories.
If we plan well and bring some extra manpower online for the re-sid we could conceivably get them into a contiguous sid range to help with automated enabling/disabling. That'll be a challenge though.
Matt
On Mar 21, 2011, at 3:46 PM, Jason Wallace wrote:
> No, it makes it easier to combine them, in my opinion, because then we
> could pick and chose between the ET distributed GPL rules and the VRT
> distributed rules. That is not possible today, because they use the
> same SID and most rule management tools are SID driven so you can't
> enable/disable a SID without SID duplication. The no-gpl model
> requires a user to either use VRT+ET-no-gpl, just the VRT, or just the
> ET set. We can't chose to use one gpl rule from the VRT and another
> gpl rule from ET, because the two can't exist at the same time.
>
> Like Mike said, the whole idea of coverage duplication being an issue
> is a completely invalid, because that is already a nightmare now.
>
> There is no valid reason to not fork and re-SID. That act will finally
> put and end to this problem and let US, the end user, make our own
> desiccation about where we get rules from without being forced down
> some predetermined path.
>
> Thx,
> Wally
>
> On Mon, Mar 21, 2011 at 3:23 PM, Matthew Jonkman
> <jon...@emergingthreatspro.com> wrote:
>> But fork and re-sid makes it tough for folks to combine the open ruleset with VRT.
>>
>> That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
>>
>> If folks are happy with not being able to easily combine with VRT then we can go that direction.
>>
PGP: http://www.jonkmans.com/mattjonkman.asc
NA
> On 3/21/2011 15:23, Matthew Jonkman wrote:
>> But fork and re-sid makes it tough for folks to combine the open ruleset with VRT.
>>
>> That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
>>
>> If folks are happy with not being able to easily combine with VRT then we can go that direction.
> file so that those who want to include it in their operations can enable it in
> their configs and everyone else can (leave them) disable(d) in their's...
>
most sense. With this idea there could even be two sets of GPL rules. A
user could enable one or the other, or neither.
My opinion is that of someone new to Snort, still tuning (still learning
to tune!), and rules are something I depend on, not attempt to write
yet. You could though easily equate my situation with a rushed admin.
.02
Bill B
NA=noob advocate? ;-)
Mike Lococo
> On 3/21/11 4:12 PM, waldo kitty wrote:
>> On 3/21/2011 15:23, Matthew Jonkman wrote:
>>> But fork and re-sid makes it tough for folks to combine the open ruleset with VRT.
>>>
>>> That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets.
>>>
>>> If folks are happy with not being able to easily combine with VRT then we can go that direction.
>>
>> please see my earlier response RE: everyone carry the GPL in a special rules set
>> file so that those who want to include it in their operations can enable it in
>> their configs and everyone else can (leave them) disable(d) in their's...
>
> After reading this thread for the last 4 days this suggestion makes the
> most sense. With this idea there could even be two sets of GPL rules. A
> user could enable one or the other, or neither.
* This prevents us from properly categorizing the GPL rules.
* It doesn't address the thousands of other cases of overlap between
the two rulesets.
* It cannot scale to address the additional cases of overlap without
completely abandoning the categorization system.
* There are other ways to enable easy rule enable/disable besides
clumping them into a single file, like a ref-tag or msg-pattern.
I know as a beginner that rule-files seem like a handy way to
enable/disable rules because it's so simple, but the fundamental problem
is that every method of organizing rule-files conflicts with every other
method and we can't do them all. Learn to use the pcre options in
pulled-pork and you'll be much better off when managing complex rulesets.
Cheers,
Mike Lococo