Let me preface my final email on this with the fact that it was just one
customer who brought his sensors down, so please, for those of you wanting
to jump in to this thread just to sling mud, be careful where its thrown. It
wasn't because of our product and it wasn't because of Applied Watch. The
individual stabs at the AWCC is trifling in attempt because in this
situation, it was merely the tool used by the individual. Matt, Frank, and
the others are right, the correction takes literally seconds to fix with
distributed Snort management systems. However, for those who don't have a
centralized management system for Snort, yes, it's a lot of VI sessions
depending on how many you have -- which I'm sure will amount to a good, hard
lesson learned.
To that end I do want to move on from this and make sure several points are
made and given their due attention. Again, the fact that some sort of
quality control or standards need to be implemented and enforced in the
bleeding-edge project. We just can't have thousands of people creating
signatures with their own variables just because they want to find notoriety
in having it added to the official snort.conf file or something they can
refer to at SUGs. I stand firm on my argument that no one can otherwise make
me see differently on that the implementation of custom variables if running
a service on a "NON-STANDARD PORT #" is not the responsibility of
Sourcefire, its not the responsibility of Bleeding-Edge, its not the
responsibility of Applied Watch, it's the responsibility of the end-user who
implements the signature. Where will it end if we continue to allow people
to begin creating variables for services they decide to run on that are
non-RFC standard port numbers? Sourcefire will eventually tell bleeding-edge
and anyone else to get lost. They don't have the time to add every variable
that Tom, Dick, and Harry want to create for their new signatures.
I can see two courses of action to prevent this in the future:
1) In the rule submission page at bleeding-edge, limit variable selection to
only those standard variables found in the official snort.conf file that the
user must adhere to.
2) Create the bleeding-edge snort.conf file and distribute it with the
tarballs.
What do I see as the best approach to this? Change Erik's signatures to be
the standard port 22 and go with option 1. How much work do we expect to all
do on behalf of the thousands of rules that come in to this project? I
personally wouldn't have time to create a new variable and add it to the
bleeding snort.conf file every time someone wants to create a
$MY_ELITE_VAR_BECAUSE_I_RUN_FTP_ON_PORT_2121_TO_AVOID_HACKS
Best Regards,
Eric Hines, GCIA, CISSP
CEO, President, Chairman
Applied Watch Technologies, LLC
1134 N. Main St.
Algonquin, IL 60102
Tel: (877) 262-7593 e:327
Fax: (877) 262-7593
Mob: (847) 456-6785
Web: http://www.appliedwatch.com
----------------------------------------------------------------------------
-
Enterprise Snort Management at http://www.appliedwatch.com.
Security Information Management for the Open Source Enterprise.
----------------------------------------------------------------------------
-
-----Original Message-----
From: Matt Jonkman [mailto:matt@infotex.com]
Sent: Wednesday, June 08, 2005 6:29 PM
To: Frank Knobbe
Cc: bleeding@bleedingsnort.com
Subject: Re: Proposal for a distributed "bleeding.conf"
Summary of my thoughts (I was out all day BTW)
I don't want to add vars on a regular basis. i want to work to get them into
the stock snort.conf from SF if we have to add them at all.
I think enough folks clearly use ssh on off ports, so the var here is
definitely useful. And universal enough because about everyone uses it.
I hope we don't have to add others, and if so we'll try again through SF.
I really like the idea of a bleeding snort conf include file. We'[d only
have one line for it at the moment, so maybe once we get more need we can
implement.
Matt
Frank Knobbe wrote:
Guys,
instead of requiring people to modify their snort.confs every time we
might throw a variable at them, how about we distribute a
bleeding.conf that people can include once with "include
bleeding.conf" and be done with it. Then we could add vars to a
bleeding.conf that we distribute without causing Snort errors. (People
still need to adjust vars to their local preferences though, and are
strongly encourages to stick them into their snort.conf _after_ the
bleeding.conf inclusion. That way bleeding.conf can act as a default
setting.
We can the file in the root of the Bleeding CVS tree. We'll just need
to adjust the scripts to create a copy on the download page.
bleeding-defaults.conf might sound more appropriate.
What do you guys think?
Regards,
Frank
--
--------------------------------------------
Matthew Jonkman, CISSP
Senior Security Engineer
Infotex
765-429-0398 Direct Anytime
765-448-6847 Office
866-679-5177 24x7 NOC
my.infotex.com
www.offsitefilter.com
www.bleedingsnort.com
--------------------------------------------
NOTICE: The information contained in this email is confidential
and intended solely for the intended recipient. Any use,
distribution, transmittal or retransmittal of information
contained in this email by persons who are not intended
recipients may be a violation of law and is strictly prohibited.
If you are not the intended recipient, please contact the sender
and delete all copies.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
