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 "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: jeffmat_private Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:52:50 PDT