>>>>> On Sat, 20 Aug 2005 21:00:26 -0700 (PDT), "David T. Perkins" <[EMAIL
>>>>> PROTECTED]> said:
David> I'm stumped.
So am I. The thread has been going on so long (* below for cool ascii
diagram) before I got to it that I'm not sure where to reply. Thus,
I'm replying at the top.
So here's the problem, and the history:
1) snmptrapd is amazingly old, like most parts of our code.
2) some of the features, however, are much newer.
3) The SNMPv3 support was done a while back with funding that was
designated to implement a reference release of the SNMPv3 specs.
Thus, we implemented all the security components *that were
specified*.
4) Thus, we implemented access control within the agent but did not
limit incoming traps, aside from being authentic and decoded
properly, from being processed by snmptrapd. There is no standard
requirement for how to decide whether to accept a trap or not. It
should *not* be based on just whether a message is authentic or
properly encoded. There should be a notion of whether or not you
actually want to process the packet based on the credentials. IE,
you're *authorized* to send me traps. I actually think that should
have been standardized with the SNMPv3 work but no one else agreed
with me (the primary argument being it's not needed for
interoperability, which is mostly right but not complete enough for
me to decide it shouldn't have been done).
5) The end result is that I've felt ashamed that I've let the
snmptrapd code rest as is for so long (so thanks for stirring the
pot).
So, the only proposals I'm willing to accept (yes, there is a large
foot coming down right now) are ones that have some thought behind
them as far as threats that you might face being a network
administrator. Here is what I think MUST be done:
1) access configuration needs to be implemented within snmptrapd.
This means that by default, snmptrapd will accept *nothing* without
something saying it should do otherwise. This is exactly how snmpd
behaves today, for example, and most people would consider it
insane that you'd do otherwise.
SNMPv1/SNMPv2c) You must list the community names you want to
accept, or I suppose allowing a '*' would be ok though I'd bet most
people wouldn't want that. Also, listing the potential hosts just
like the VACM code does today would be a good thing.
SNMPv3) You'd have to list the security model/level/secName allowed
to send you traps.
2) The *type* of things allowed to be done based on the above would
also need to be specified in the config file. IE, logging may
require less protection than execution.
3) there should be a new token that would make additional output
listing how the message was received. I don't think this can be
turned on automatically for backwards compatibility reasons (since
anything parsing the output would need to be changed).
4) Anything not meeting these criteria should be dropped.
5) Dave P's suggestion of 'say something was dropped' is fine except
that:
a) it shouldn't be on by default
b) Dave S is right that you *shouldn't* continue processing because
it's opening yourself to more DoS attacks by doing the rest of
the processing. Security systems are designed so you discard
bad stuff as quickly as possible without doing the more
expensive pieces first so that you don't run into the condition
where you're doing a ton of parsing of bad packets. For one
thing, if you send me an unauthentic packet the *last* thing I
want to do with it is parse it to find out that you're trying to
exploit a weakness in the immediate to follow BER decoder, the
later print logging system, or even later in the things that
parse the output of snmptrapd. Passing things on beyond that
should *never* be enabled by default and I'd argue it shouldn't
be turned on. Printing "packet dropped" would be ok, on the
other hand IMHO, but potentially it should be off by default
though (to prevent log filling) I'm less picky about that one.
c) It violates the USM RFC to continue processing unauthentic
packets by the way. Dave P should know this. You return an
error code and don't parse the packet.
I think there was more I wanted to say, but I don't remember it at the
moment.
I do think sending TRAPs in SNMPv3/USM sucks. As does sending
INFORMs, but for different reasons. We should try and do something to
help ease that, I agree. But adding less security is not the way to
do it. snmptrapd has been to *insecure* for way way too long. I'd
love that guilt to be over. The good news is that I think I can
actually devote the time to help fix it.
/me wonders how much of the VACM code could be leveraged to apply
here... Much of the requirements are actually similar.
--
Wes Hardaker
Sparta, Inc.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
