nmap UDP portscan reaps snmpdm on scaned node; known bug?

[Ralph Grothe]

Hi,

I stumbled over this threatening "feature" of nmap while I was running scans on some of our (firewalled) HP MC/SG servers to find out if 161/udp PDUs were rejected.
Having run my Net::SNMP script that incorporated the hpmcSG OIDs (kindly posted by Melvyn Burnard, as these MIBs are usually part of OpenView which we don't have (see http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=105704)) against a node that wasn't firewalled, and where I received a valid reponse PDU, I wanted to double check with nmap (viz. to find out the right options to use for the firewalled nodes).
Because the usual (TCP?) scan (e.g. nmap -p 161 ) only would report the port as closed I tried nmap's -sU switch, which of course required root privileges.
When I did run this scan the SNMP master daemon on the scaned server got reaped (while the cmsnmpd to whom I GET request should have been delegated survived).
This looks bleak, is it that easy to reap the snmpdm?
Has anyone heard of a related bug in snmpdm?
Or were I simply "abusing" nmap (but then, anyone with root access in our LAN could do so).

After having restarted snmpdm through its init script /sbin/init.d/SnmpMaster my Net::SNMP requests continued being answered, and the service is available on 161/udp

# netstat -anfinet|awk '$4~/\.161$/'
udp 0 0 *.161 *.*

# /usr/local/sbin/lsof -iudp:161
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
snmpdm 10473 root 5u inet 0x5748f668 0t0 UDP *:snmp (Idle)

[Ralph Grothe]

Woah, I should have read the nmap Manpage more carefully where the following warning appears at the end
(I don't know if HP would consider the snmpdm as a "poorly written" application ;-)



It should also be noted that Nmap has been known to crash
certain poorly written applications, TCP/IP stacks, and even
operating systems. Nmap should never be run against unless
you are prepared to suffer downtime. We acknowledge here
that Nmap may crash your systems or networks and we disclaim
all liability for any damage or problems Nmap could cause.

[rick jones]

Re snmpdm a poorly written application? Who knows :)

Something like that sounds like a DOS path, and if it is already known, I suspect that an HP Security Bulletin would have been posted about that. I'm sure they are stored somewhere in the ITRC, and they get posted to netnews in comp.sys.hp.hpux so you could look there. The usual song and dance about looking for the latest SNMP patches for your OS rev would apply as well, and if after that nmap still kills the snmpdm it is time to open a call with the Response Centre.

[Ralph Grothe]

Hi Rick,

I did as you suggested, and queried the HP patch database.
What I found were these

http://www4.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main%7Cpatch.breadcrumb.search%7Cpatch.breadcrumb.cart%7C&patchid=PHSS_27858&admit=-938907319+1095068338273+28353475&context=hpux%3A800%3A11%3A00

http://www4.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main%7Cpatch.breadcrumb.search%7Cpatch.breadcrumb.cart%7C&patchid=PHSS_29857&admit=-938907319+1095068460342+28353475&context=hpux%3A800%3A11%3A00

I found none of them installed on our box.
However, I don't know if they even apply as I'm not using HP network managing software (like OpenView), but rather my own scripting solution (I think I also should have a look at http://www.nagios.org/).

Is the Emanate agent another coining for the standard suite of HP-UX SNMP agents, or does it relate to a different product (then I could ignore the patch).

I still struggle with another wee problem.
Since I cannot resort to a comfortable OV import I do have to manually sift through the data structure of the response PDU from my Net::SNMP object and compare it to the hpmcSG MIB file that was published here in another thread by Melvyn Burnard.
(I think the MIB file gets installed automatically on those boxes that run an OV manager when one also installs the ClusterView SW)

While trying to match OIDs for objects hpmcSGPkgNode and hpmcSGPkgNodeRank I realized that I probably miss MIB parts (i.e. those that are imported)



HP-MCSG DEFINITIONS ::= BEGIN


IMPORTS
hpmcNodeID, hpmcNodeName, hpmcClusterIndex, hpmcClusterName, hpmcClusterState
FROM HP-MCCLUSTER



I especially require the hpmcNodeID because I cannot safely map for instance those OIDs from my response PDU:



'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32527.1' => 1
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32527.2' => 3
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32528.1' => 2
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32528.2' => 3
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32529.1' => 3
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32529.2' => 2
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32530.1' => 3
'1.3.6.1.4.1.11.2.3.1.6.3.1.1.4.5.1.2.32530.2' => 2



These OIDs belong to the hpmcSGPkgNode.
The trailing 5 digit (OID)nodes are the IDs of the cluster packages (which I'm able to map).
The values for these (hash)keys are simply 1, 2, or, 3 (i.e. the cluster nodes).
But I can only map them propperly if I knew which index related to which node.

Since you and Melvyn seem both to work for Hp,
could you trigger Melvyn to publish the missing MIB imports as well, or tell me what SW depot needs to be installed where those are part of?

Many thanks for your patience.

[rick jones]

If the Emanate stuff isn't installed on your box, then when you go to install the patch, swistall should emit a message/warning/error to that efect and not install the patch.

As for the imported MIB stuff, while I claim to be a networking guy, the details of MIB's can make my head swim :) Still, if I get a chance I'll talk to Melvyn.