SNMP with Netwitness Appliances – Put it all together 11.x

Document created by Thomas Jones Employee on Jul 8, 2019Last modified by Thomas Jones Employee on Jul 8, 2019
Version 2Show Document
  • View in full screen mode

Scenario –
You or your customer would like to link SNMP to the Netwitness for system monitoring purposes (Solarwinds, Nagios, etc.).


SNMP is an “agentless” method of monitoring network devices and servers, which can be viable alternative to the problems, hassle, and maintenance associated with agents.


The process:

  1. Preparation
    1. How many hosts
    2. Host locations and subnets
    3. ssh access
    4. Documents
  2. Obtain the snmp script for netwitness (there may be other versions available)
  3. Considerations
    1. Change requests?
    2. Schedules
    3. Implementation
    4. Manual configuration or script
    5. Backout process
    6. Expectations from the other stake holders
  4. Backup
    1. Netwitness.json (/etc/netwitness/config-management/environments/netwitness.json)
    2. Iptables-config (/etc/sysconfig/iptables-config)
    3. Iptables (/etc/sysconfig/iptables)
    4. SNMP (/etc/snmp/snmpd.conf)
  5. Implementation – Short version
    1. Each host will need the netwitness services stopped before the system is configured for SNMP.
    2. If netwitness is already deployed and the firewall rules during the install were not set to custom the netwitness.json file will need to be modified so that future updates and upgrades do not change the firewall rules.
    3. Modify the iptables-config (configuration for firewall rules)
    4. Modify the iptables files (firewall rules)
    5. SNMP default port 161
    6. Optional – it is also a good time to add icmp if desired.
    7. Run the script
    8. Modify the snmp.conf file
    9. Restart the firewall service
    10. Restart the snmp service
    11. Restart the netwitness services
  6. Testing
    1. Snmpwalk command is the best way to test.
    2. First, run the snmpwalk on the current host
    3. Second, use the snmpwalk from a different host


Sounds pretty easy, right?  There is a lot going on with this process, so here is the detailed break down.


  1. Backup
    1. Netwitness.json (/etc/netwitness/config-management/environments/netwitness.json)
    2. Iptables-config (/etc/sysconfig/iptables-config)
    3. Iptables (/etc/sysconfig/iptables)
    4. SNMP (/etc/snmp/snmpd.conf - if exists)
  2. Stop all the services for netwitness (choose one of these host types - Network only - the basics).  Possible host types: Archiver, Broker, Concentrator, Decoder, EndpointHybrid, EndpointLogHybrid, ESAPrimary, ESASecondary, LogCollector, LogDecoder, LogHybrid, Malware, NetworkHybrid, UEBA.  Please reference the community docs for additional appliances.
    1. SA Server
      1. systemctl stop jetty.service
      2. systemctl stop nwappliance.service
      3. systemctl stop nwbroker.service
      4. systemctl stop rsa-nw-admin-server.service
      5. systemctl stop rsa-nw-config-server.service
      6. systemctl stop rsa-nw-content-server.service
      7. systemctl stop rsa-nw-integration-server.service
      8. systemctl stop rsa-nw-investigate-server.service
      9. systemctl stop rsa-nw-orchestration-server.service
      10. systemctl stop rsa-nw-respond-server.service
      11. systemctl stop rsa-nw-security-server.service
      12. systemctl stop rsa-nw-source-server.service
    2. Broker
      1. systemctl stop nwappliance.service
      2. systemctl is-active nwbroker.service
    3. Decoder
      1. systemctl stop nwappliance.service
      2.  systemctl stop nwdecoder.service
    4. Concentrator
      1. systemctl stop nwappliance.service
      2. systemctl stop nwconcentrator.service
    5. ESA Primary
      1. systemctl stop rsa-nw-contexthub-server.service
      2. systemctl stop rsa-nw-esa-analytics-server.service
      3. systemctl stop rsa-nw-esa-server.service
    6. ESA Secondary
      1. systemctl stop rsa-nw-esa-analytics-server.service
      2. systemctl stop rsa-nw-esa-server.service
  3. Update the files
    1. Netwitness.json
      1. "global" : {
        "customer-firewall" : true,
              "mongo" : {
    2. Iptables-config
    3. Iptables (make sure the rules are put at the top and not the bottom)
      1. OPEN the SNMP default port 161
      2. A INPUT -p udp -m udp --dport 161 -j ACCEPT
      3. Optional – Open icmp if the environment relies on ping for management purposes
      4. -A INPUT -p icmp -j ACCEPT
    4. Set up SNMP
      1. chkconfig snmpd on
      2. Run the following script or later version
        2. Don’t forget to change the permissions
      3. Snmpd.conf
        1. Uncomment and/or modify
        2. (uncomment) # master agentx to master agentx
        3. rocommunity netwitness
        4. (uncomment and add <ip.addr>) # agentaddress 192.x.x.x
          1. this is typically the ip address associated eth0 (bonded) or em1 on netwitness hosts
        5. trapcommunity netwitness
          1. this is normally the trap community the designation you obtain from an administrator – ex.ABC#$%123
    5. Restart all the services
      1. systemctl restart snmpd.service
      2. systemctl restart iptables.service
      3. Restart the appliance Netwitness services
    6. Testing
      1. Run the snmpwalk locally
        1. snmpwalk -v2c -Of -c netwitness -m "/usr/share/snmp/mibs/NETWITNESS-MIB.txt" .
        2. snmpwalk -v 2c -c "communityName" x.x.x.x
      2. Run the snmpwalk from a different server.
        1. snmpwalk -v2c -Of -c netwitness -m "/usr/share/snmp/mibs/NETWITNESS-MIB.txt" <ip address of the queried nw host> .
      3. Have the administrator snmpwalk test
        i. snmpwalk -v 2c -c "communityName" x.x.x.x


If you are doing a larger deployment, I would highly recommend scripting the process and as a best practice do your development in a test environment.


How did I do this in my most recent deployment?

Customer was on with network only.  32 Hosts.


I started by referencing the documents above and the web for the script outline.  I then scripted out the process, loaded the scripts on the SA head (MyScript and  I pushed them out with the salt-cp '*' file.copy command to all the hosts.  I then changed the scripts permissions with the salt '*' 'chmod...'.  At this point, I had put the files on all 32 hosts and ready to be run.  Because I wanted to ensure there were no problems, I ssh'd into all the hosts and ran the scripts manually.  Lastly, I would advise being careful with the salt '*' command because that updates all the hosts at once.  Alternately, the salt command can be used targeting one host by using the salt minion id.  Ex. salt '32b78ed8-a0dc-4f4c-915f-ec14aeacf6hf' 'enter your command here'


Moving forward as we add additional hosts, I will simply WinSCP the scripts on to the new host, change the permissions, and run the scripts.


Let me know your thoughts - Tom J