[Snort-devel] Re: MIB/SMNP Issue

Rob Hughes rob at ...825...
Sun May 12 07:30:03 EDT 2002

On Sun, 2002-05-12 at 08:50, Glenn Mansfield Keeni wrote:
> So the next question is when is this plugin going to appear ?
> Umm... let me get the documentation in place; should be anytime now!
> Glenn
I await the opportunity to test> Rob,
> Rob Hughes wrote:
> > On Sat, 2002-05-11 at 19:54, Glenn Mansfield Keeni wrote:
> > 
> >>Rob,
> >>
> >>Rob Hughes wrote:
> >>
> >>This does not seem to be the correct direction. If you will let me know
> >>what is the problem with the intergration.  I can try to help.
> >>
> > 
> > Still digging, and still finding weirdness. Attached is a text file of a few events 
> > dumped from OVO for comparison. Notice that some of the variables are not passed 
> > consistently in the traps. In particular, the src/dst mac, port and address seem to 
> > be passed differently in some of the traps. Why is this?
> The notification mechanism used by the Snort implementation uses all the
> notification MOs as optional. If there is no value associated with an MO
> then the MO is not reported in the Notification. This saves on bandwidth
> and provides flexibility (include as much information as is available).
> But this variable format has caused problems with fixed format
> notification receivers. So, I have prepared an update. I have
> defined new incarnations of the Notification objects. These
> Notifications have some mandatory objects and some optional objects.
> The mandatory objects will always be present in the respective
> Notification. The optional objects will be present by default. [The
> MIB definition now describes the MO value to be used when the value of
> the MO is not known, not available or, not applicable.]
> A new parameter is added to the snmpTrap output plugin - this parameter
> allows one to configure snort to send compact notifications - MOs for
> which no information is present are not sent in the notification.
> This should solve most (if not all) the problems for the time being.

Then I shall await the opportunity to test it with baited breath :)

But seriously, now that I'm an independent consultant and am finally
allowed to advocate for the products *I* think are best instead of
whatever partnership the company I work for wants pushed, I've been
recommending snort to my clients in the vast majority of cases. Some are
starting to listen, and since most are heavy OpenView shops, that's
where I've started my integration efforts. From the MIB standpoint
though, I've worked with other trap receivers, and most seem to work
pretty much the same, at least as far as the commercial ones. OpenNMS is
a bit different. Since you can define all your traps via XML, you can
put pretty much whatever you want in there.

Still working on the problem of the match condition though. All OV
products seem to expect traps, whether v1 or v2* to follow the same
conventions. Again, this is demonstrated by NNM's insistence that the
enterprise for Snort isn't present in the trapd.conf when attempting to
configure it from the event browser. Does your solution take this into
account? Granted, this may not be a truly big issue, but it might affect
a customer's decision if their engineer is bothered by it, and I'm sure
you're familiar how some engineer's are.

At any rate, I do have it working. It just doesn't seem to be a "clean"
as it could be.


More information about the Snort-devel mailing list