SNMP communities in 3Com HiPer Arcs (maybe other 3Com products?)

[jeffm () IGLOU COM (Jeff Mcadams)]

Well...I hate doing this...but it can't be said that I didn't give them
time to fix this...I first notified 3Com about this in early Feb.

The 3Com HiPer Arc cards are the new generation access server cards for
the Total Control Access Server system.  These cards use the "Pilgrim"
code base for their software.  I've been told by some people at 3Com
that this code base is going to be the code that, eventually, all of
their routing products will be running.

I have experience specifically with HiPer Arcs in Total Control
racks...but because the code base that is commonly called "Pilgrim" is
shared with several other products within 3Com (and soon to be more
apparently) this problem might be more widespread...I don't have access
to other types of 3Com equipment to check.

The impact is that anyone with any SNMP access to the box is likely to
be able to elevate their access to the highest level of access defined
on the box.

There are three levels of access on HiPer Arcs...read only, read write,
and administrative.

The crux of the problem is simple...the usrSnmpCommAccess and other
related SNMP tables and values are fully readable by all access levels.

This means that someone with a read-only community string can read the
community table and see what read-write and administrative community
strings are defined on the system to be used.

There are several workarounds.

First, the Arcs allow you to specify specific IP addresses or IP address
pools from which SNMP access will be allowed for each community string.
Setting these restrictions will restrict access for specific community
strings for specific hosts, which...while not being great, is better
than nothing.  This also still allows the other community strings to be
readable, if not useable, and could possibly be used in other places.

The other workaround is to not define any community strings on the Arcs
at all.  SNMP access can still be granted to the Arc, just not directly.
The Total Control access systems have a Network Management Card which is
used for most SNMP access to the Total Control components.  The Arc has
its own agent, other cards use the NMC card for their agent.  The NMC
can be used as an SNMP relay agent on behalf of the Arcs.  The procedure
to do this is to specify the NMC's community string with "@<entitynum>"
appended on the end.  <entitynum> is a value used internally in the
chassis to refer to specific components of the system.  For example, the
card in slot 16 (typically the HiPer Arc) has an entitynum of 16000.
The card in slot 5 would be an entitynum of 5000.  The third modem on
the card in slot 5 would be an entitynum of 5003.  So, to send an SNMP
command to the Arc, assuming its in slot 16, and assuming an NMC
community string of "public" for example purposes, you'd use the
community string of "community string of "public@16000".  The only real drawback to this
workaround is the extra load that is put on the NMC cards (many of which
are only 486 processor based...none-too-overpowered), and that the SNMP
operations are slowed down by having to be processed through another
system.

Anyway...I first mentioned this to 3Com in early Feb.  There has since
then been a fairly major code release on the HiPer Arc code with no
change to this problem (4.1.x -> 4.2.x).  I did get an acknowledgement
when I first posted the problem to 3Com that they were aware of it and
working on it.  Perhaps full disclosure will accelerate their work a
bit.

--
Jeff McAdams                            Email: jeffm () iglou com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456