IBM Support

nmon Data Files: Are they a Security Risk?

How To


Summary

Performance data is not personal but are there some details you need to hid?

Objective

Nigels Banner

Steps

People share nmon captured data files with me all the time because they would like me to review the data and make suggestions about the hot spot and tuning.

I guess they trust me :-)

Some users get a little paranoid about the data (mostly due to having to follow many procedures to get the nmon file through firewalls so it can be emailed to me) and ask questions about if it contains the information they don't want to accidentally share. Thankfully the nmon data file is just a text file that you can edit with "vi" so there is nothing hidden about the contents.  I guess the bottom line questions are

  1. Does nmon help an evil hacker?
  2. Does nmon reveal any facts we don't want public?
  3. Would the information help a competitor?

So here is a list of the items that could be removed - to be blunt it was hard to think of any:

  • The filename contains the hostname and the hostname appears multiple times in the file too

    Some users use simple hostnames that have meaning like db2server9 and others complicated letters and numbers that are meaningless without the "secret decoding ring" and even then it reads more like a part number for a tractor than anything useful. I was told that the longest-running PMR in IBM history was due to two machines having similar names so the problem was on one machine but the customer was getting diagnostics from the other machine - it took weeks to sort out as the diagnostics files proved there was no problem at all!!

    The hostname is in the configuration data and in the section header line for each type of statistic CPU, MEM, DISKBUSY and so on. This is so it appears in the graph titles. As there is only one hostname it is easy to identify.

    Security Risk?  Extremely low and simple to remove with a sed script in under a second.
     
  • There are a few IP addresses in the network configuration

    These are in the configuration section: lsconf command output, the network details ifconfig command and netstat command.
    In addition, to the IP Address of the LPAR or virtual machine itself, there can be other IP Addresses due to network aliases and routes to other machines.
    This means a simple sed script can't remove anything beyond the prime IP address and would need a quick inspection of the output of the commands above. Although removal of lines containing "ifconfig", "netstat" remove that risk. The "lsconf" data is genuinely useful so remove lines with lsconf AND "Host Name" plus "Gateway" has it covered.

    Security Risk? If keeping IP Addresses secret is regarded as a security measure ... you have lots more problems than nmon files!  IP Addresses can be determined easily enough by a simple ping script and port scanning. A four-line grep script can remove the items above.
     
  • The filesystem mount point for directories sometimes includes product names. If you included in the nmon command the options -t or -T then you have Top processes command name and these can include product names. So can the "ipcscommand output as it includes the user name owning shared memory, semaphore, and message queues which can be product names.

    Some products strongly recommend specific install or data directory names. The most obvious one is Oracle with mount point directories like "/ora01" (there is a whole manual describing what to call them) but there are other examples.  This convention saves time grubbing around looking for where the code or data is placed. These are listed in the nmon data file be the "mount" and "df" command sections.

    For the process names a simple example is something like "db2inst1" the universal program that runs the DB2 database. The same goes for "oracle" processes. These only get captured with the -t or -T options.

    The ipcs output includes the user names that own resources and ironically both"oracle" and "dbinst1" would appear if installed.

    Security Risk?
    Well not really - unless you are worried that people will know some of the products you are using. That is high up the paranoia scale. 

    Most large companies have employees that previously worked with a competitor and will list the products used for the price of a cup of tea! You could probably get the information from a good search of the WWW - from lists of customers using a product, presentations at conferences or product problems, and fixes database and user forum questions.

    Removal is hard because this information is useful for configuration understanding and performance tuning.  For mount points - check the "mount" and "df" command output sections.  Don't collect top process data and remove the "ipcs" command output. If you know the commands and users a product will use you could use sed to rename them so for example "oracle" becomes "RDBMS".

Summary:

  • There are a few "small beer" networking items but nothing serious that would assist an evil hacker.
  • Worrying about the product names might be going over the top.

So do nmon data files present a security risk - IMHO I think not but you have to make up your own mind.

Additional Information


Other places to find content from Nigel Griffiths IBM (retired)

Document Location

Worldwide

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"","Platform":[{"code":"PF002","label":"AIX"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"HW1W1","label":"Power -\u003EPowerLinux"},"Component":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 June 2023

UID

ibm11116237