[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: security for snmpbulk transfers
>While I appreciate your points, our customers that we have had extensive
>communication with have supplied us with RFIs that specifically state the
>ways in which they want to use bulk statistics implemented. Additionally,
>the specs have been laid out as a push model. This only makes sense because
>the element knows when it has data to push. Going to a pull model is what
>they are getting away from.
being in the business of shipping products that meet customer
requirements, I'll mostly take my lead from them. if we produce a
product that isn't field-acceptable, we'll know about it pretty
quickly, I would think.
>So I was whining about having a username/password for a statistics server
>in a managed device at the EOS meeting and thought I'd carry that whining
>on to the list.
>Bottom line: I really don't think this is going to fly. Statistics
>information used for billing and accounting is considered extremely
>sensitive by providers. I don't think providers, particularly telcos, are
>going to be at all thrilled at putting that information in their network
as I said at the presentation, I'm not real religious about how the
authentication is done. security isn't my primary area of expertise
and I'll be happy to include other models that the experts consider
more secure than simple username/passwords. however, interoperability
was one of my chief goals, and stock FTP can't use more than u/p
combos. ssh/scp can go beyond u/p model and so I'm happy to include
whatever fields and descriptors we need to support all the current
methods of remote ssh login authentication.
>There are a couple ways of dealing with this that I can think of off the
>top of my head:
>1) Move from a push to a pull model. The SNMP agent modifies a MIB
>variable to indicate that it is ready to transmit data via the oob channel
>specified and then the management station should connect and collect the
there is nothing in the current proposal that prohibits using the pull
model, at least in terms of the file-transfer trigger, itself. to
cause the file transfer to occur, you simply do an SNMP set to a
RowStatus variable. this can occur locally (from the agent to itself)
or remotely via an NMS.
if you were referring to actually _being_ an ftp/scp server (in your
comment about the pull model), I'd have to disagree with this
approach. there were comments at the presentation about footprint
size on the managed element; if we had to include an ftp/scp/whatever
server as well as client, I think this would be more than most vendors
would want to support (except for maybe an http server, which seems
all the rage amongst current comms equip. vendors). and its my belief
that securing a fileserver is much more involved than securing a
mere client. afterall, if we're acting as only a client, there are no open
ports, no daemons to worry about, and just less hassle overall.
>2) A careful specification of how to secure the statistics server. In
>this case what we want is compartmentalization. The agent pushes the
>collected statistics to a write-only filestore. This is really more of a
>policy issue in general but we need to specify name collision behaviour
>because we cannot overwrite files. It'd be nice to specify a way for the
>router to authenticate using its private key, if it has sshd support.
I like the idea of a write-only server, but as you say, this is an
operational decision and is entirely outside the agent's area of
concern. I'd prefer that the agent not have to force a security
policy on external boxes since this decision really belongs at the
site/ops level. as long as the versioning support at the client side
(bumping up a version field when filename collision occurs at transfer
time) can deal with read/write and write-only ftp/etc servers (and
I'll ensure my implementation can), the local site can follow whatever
level of security it feels comfortable with.
>Pros: Decent security potential as long as proper guidance is given.
>Worst case scenario is that that a compromised agent could perform a DoS
>attack on the statistics server. You could argue that with proper quotas
>set, this DoS attack could be limited to only logging for the compromised
>box, which you can't trust now anyway.
if there's anything we can do at the agent side to reduce the chance
of a DoS attack originating from us, I'll be happy to include it.
however I think this is mostly implementation-specific and that there
isn't a whole lot at the MIB specification level that could be
included to address this issue.
Bryan Levin, Allegro Networks