HI, Right this freaking minute I'm trying to figure out why snmptrapd believes that I've got an unknown user (printed when I have -Dusm). I thought I tested this and knew how to configure snmptrapd. Maybe it has something to do with the clocks.
In any update, there HAS TO BE a way to tell snmptrapd to indicate for every received trap or inform the status - proto (v1, v2c, v3/usm) type (trap, inform), sec level (noAuthnoPriv, etc), sec params, was it authenticated (and decrypted) OK. If it works one way for SNMPv1 and v2c, but differently for V3/USM - that is really bad. Got to go. More tomorrow. On Fri, 2 Sep 2005, Wes Hardaker wrote: > >>>>> 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. > Regards, /david t. perkins ------------------------------------------------------- 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
