[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: security for snmpbulk transfers


Telco's and large service providers put this information in their devices
today and it is extremely common practice. They set up username/password
combinations for exception dumping as well as existing bulk statistics
shipping code. With these services, they put username/password combinations
locally defined within the router and the passwords are MD-5 hashed. These
services are done on the out-of-band management networks of the major
providers. This out of band network is typically connected via an 100Mbps
Ethernet port on the management blades within large scale routers (OOB
Ethernet port).

A well known DSL subscriber platform which has one of the largest install
base uses their own version of bulk statistics blatantly store the username
password in their configuration file and it is used all throughout the
world. Their command structure for storing the username/password locally is
the following:

receiver <ip address> primary mechanism ftp login <name of login> password
<password> passive

This command structure lives locally in the router.

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.

Additionally most well known large router vendors also have additional
services that store AAA local services with local username/password
combinations within their routers. Again, these passwords are MD-5
encrypted. This is extremely common practice for local privilege levels and
these particular vendors have been doing this for years. If this was
unacceptable, surely we would not continue to see this service defined on
RFI's from major carriers as well.

In order to get authenticated, authorized, and accounted for, carriers imply
major security elements to their devices. This includes everything from AAA
to access-lists, as well as using newer secure mechanisms like SSH and S-FTP
as well as SCP.

With AAA, routers talk to external TACACS+ or Radius servers which in fact
many times talk to Security Dynamics ACE servers that generate one-time
passwords for users to even get authenticated to the devices. Trying to
breach the routers themselves where the username/passwords are MD-5 hashed
is not of the charter in the EOS working group. The current implementations
are extremely secure.   Remember, the username/password combination that we
are talking about is for the OOB network FTP/S-FTP server not the router.
Because the data (username/password) and server are on the out-of-band
networks, this is a non-issue in the current way that Telco's/service
providers operate today. If their OOB networks have a security breach, many
of the incumbent router vendors don't disable telnet, so they would have a
lot more to worry about as far as clear text for sniffing.

I would like to hear from some carrier customers that have not used current
security practices (TACACS+, Radius, exception dumping, current bulk
statistics implementations, and local AAA services as well as a host of
others that do this practice today) because of storing local usernames
and/or passwords that are MD-5 hashed in the local routers. Both exception
dumping and bulk statistics are done in a push model by the most common

The use of local username/password within the element is today's practice
for quite a number services and accepted by every company we have spoken
with. Let's hear from carriers that have a problem with this on this list.


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

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

Pros:  Best security of what I'm about to list and what's been proposed in
the WG.  Authentication credentials are stored only on the management
station or statistics server.
Cons:  Requires explicit support for bulk transfer on the manager.  It's
possible that agent will run out of caching room while waiting for the
manager to download (although I'd argue that a proper implementation would
not have this problem).

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.

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.
Cons:  It'll be easy for operators to misconfigure server security in this


Matt White
Ericsson IPI