[Snort-devel] spo_SnmpTrap.

Glenn Mansfield Keeni glenn at ...1085...
Fri Oct 11 04:08:02 EDT 2002


Andrew,
      I did think twice or thrice before deciding to do the
patch that way. We do not want to keep ourselves in sync
with the net-snmp command line options. That way every time
there is a change - the snort-conf's will have to change.
The move is towards a simpler interface that works for the
snort-conf snmptrap activation line. The present version
came out after several iterations and I really like it the
way it is. [ Most of the other trials would not work for
this reason ot that. Default port is not right/Colon
separated port number is not accepted in ucd-snmp etc.]
      Regarding the IPv6 addresses and transport domains
the discussion has been on for some time on the net-snmp
list and we did prepare a patch to have IP-addresses in
braces. That probably got lost. Will dig that up again
and send it to the list.

       Glenn

Andrew Hood wrote:
> Glenn Mansfield Keeni wrote:
> 
>> Hi,
>>    The net-snmp support for the snortSnmp plugin ran into
>> some rough weather - the port specification convention has
>> changed, the community specification convention has changed
>> and the default port selection logic seems to be buggy in the
>> present net-snmp release (5.0.5).
>>    A patch for the spo_SnmpTrap plugin has been readied - this
>> will work with minimal changes to your snort.conf. There is only
>> one change - if you are using v2c then the community MUST be
>> specified using the '-c <community>' option BEFORE the
>> snmptraplistener address. [Community after the snmptraplistener
>> address will not be accepted]
>>    The comments in the snort.conf and the explanation in the
>> doc/README.SNMP have been updated to that effect. The patch is
>> available on
>>
>> http://www.cysol.co.jp/contrib/snortsnmp/SnortSnmpPatch-1.9.0-01.gz
>>
> 
> 
> Having looked at the patch, I don't think this is the way to go. Rather 
> than duplicate the function of snmp_parse_args it would be much cleaner 
> to bite the bullet and force people to fix their snort.conf. They 
> already have to fix the community string for SNMP version 1 or 2c.
> 
> 
> "udp:hostname.some.org:snmptrap" should be a legal destination string 
> for net-snmp. Do you really want to duplicate the code to allow for all 
> possible parses?
> 
> The issue of not being able to deal with colon separated IPv6 addresses 
> should be referred to the net-snmp list. They will need to deal with 
> this. I will submit this question to them
> 
> It is quite possible net-snmp will find some new use for the p option. 
> Maybe it will need to be reused to cope with IPv6.
> 
> Andy
> 








More information about the Snort-devel mailing list