METRON-2216 Upgrade Core Enrichments for HBase 2.0.2

[nickwallen]

This change upgrades the core Enrichment components to work with HBase 2.0.2. This PR is for the feature/METRON-2088-support-HDP-3.1 feature branch.

This change should be tested in the CentOS 6 dev environment with HDP-2.6. These are backwards compatible HBase changes that require additional changes before everything can be compiled under HDP-3.1.

Changes

1. Created the FakeEnrichmentLookup which allows us to perform enrichment lookups during testing in cases where we are not able to run HBase in-memory. This replaces the "mock" Hbase mechanism that will not work in HBase 2.0.2.

2. Updated the Stellar ENRICHMENT_GET for HBase 2.0.2.

3. Updated the Stellar ENRICHMENT_EXISTS for HBase 2.0.2.

4. Updated the legacy HBase adapters for HBase 2.0.2.

Acceptance Testing

Basics

Verify data is flowing through the system, from parsing to indexing

1. Launch the development environment.

   cd metron-deployment/development/centos6
   vagrant up
   

2. Open Ambari and navigate to the Metron service http://node1:8080/#/main/services/METRON/summary

3. Open the Alerts UI

4. Verify alerts show up in the main UI - click the search icon (you may need to wait a moment for them to appear)

5. Head back to Ambari and select the Kibana service http://node1:8080/#/main/services/KIBANA/summary

6. Open the Kibana dashboard via the "Metron UI" option in the quick links

7. Verify the dashboard is populating

Enrichment Stellar Functions in Storm

1. Follow instructions similar to these to load
   the user data.

2. Create a simple file called user.csv.
   jdoe,192.168.138.2

3. Create a file called user-extractor.json.

   {
     "config": {
       "columns": {
         "user": 0,
         "ip": 1
       },
       "indicator_column": "ip",
       "separator": ",",
       "type": "user"
     },
     "extractor": "CSV"
   }
   

4. Import the data.

   source /etc/default/metron
   $METRON_HOME/bin/flatfile_loader.sh -i ./user.csv -t enrichment -c t -e ./user-extractor.json
   

5. Validate that the enrichment loaded successfully.

   [root@node1 0.7.2]# source /etc/default/metron
   [root@node1 0.7.2]# $METRON_HOME/bin/stellar -z $ZOOKEEPER
   
   [Stellar]>>> ip_dst_addr := "192.168.138.2"
   192.168.138.2
   
   [Stellar]>>> ENRICHMENT_GET('user', ip_dst_addr, 'enrichment', 't')
   {ip=192.168.138.2, user=jdoe}
   

6. Use the User data to enrich the telemetry. Run the following commands in the REPL.

   [Stellar]>>> bro := SHELL_EDIT()
   {
    "enrichment" : {
      "fieldMap": {
        "stellar" : {
          "config" : {
            "users" : "ENRICHMENT_GET('user', ip_dst_addr, 'enrichment', 't')"
          }
        }
      }
    },
    "threatIntel": {
      "fieldMap": {},
      "fieldToTypeMap": {}
    }
   }
   [Stellar]>>> CONFIG_PUT("ENRICHMENT", bro, "bro")
   

7. Wait for the new configuration to be picked up by the running topology.

8. Review the Bro telemetry indexed into Elasticsearch. Look for records where the ip_dst_addr is 192.168.138.2. Ensure that some of the messages have the following fields created from the enrichment.

   • users:user
   • users:ip

   {
     "_index": "bro_index_2019.08.13.20",
     "_type": "bro_doc",
     "_id": "AWyMxSJFg1bv3MpSt284",
     ...
     "_source": {          
       "ip_dst_addr": "192.168.138.2",
       "ip_src_addr": "192.168.138.158",
       "timestamp": 1565729823979,
       "source:type": "bro",
       "guid": "6778beb4-569d-478f-b1c9-8faaf475ac2f"
       ...
       "users:user": "jdoe",
       "users:ip": "192.168.138.2",
       ...
     },
     ...
   }
   

Legacy HBase Adapter

We are going to perform the same enrichment, but instead using the legacy HBase Adapter.

1. Use the User data to enrich the telemetry. Run the following commands in the REPL.

   [Stellar]>>> yaf := SHELL_EDIT()
   {
     "enrichment" : {
       "fieldMap" : {
         "hbaseEnrichment" : [ "ip_dst_addr" ]
       },
       "fieldToTypeMap" : {
          "ip_dst_addr" : [ "user" ]
       },
       "config" : {
         "typeToColumnFamily" : {
           "user" : "t"
         }
       }
     },
     "threatIntel" : { },
     "configuration" : { }
   }
   [Stellar]>>> CONFIG_PUT("ENRICHMENT", yaf, "yaf")
   

2. Wait for the new configuration to be picked up by the running topology.

3. Review the YAF telemetry indexed into Elasticsearch. Look for records where the ip_dst_addr is 192.168.138.2. Ensure that some of the messages have the following fields created from the enrichment.

   • enrichments:hbaseEnrichment:ip_dst_addr:user:ip
   • enrichments:hbaseEnrichment:ip_dst_addr:user:user

   {
     "_index": "yaf_index_2019.08.15.03",
     "_type": "yaf_doc",
     "_id": "AWyTZAwEIFY9jxc2THLF",
     "_version": 1,
     "_score": null,
     "_source": {
       "source:type": "yaf",
       "ip_dst_addr": "192.168.138.2",
       "ip_src_addr": "192.168.138.158",
       "guid": "6c73c09d-f099-4646-b653-762adce121fe",
       ...
       "enrichments:hbaseEnrichment:ip_dst_addr:user:ip": "192.168.138.2",
       "enrichments:hbaseEnrichment:ip_dst_addr:user:user": "jdoe",
     }
   }
   

Pull Request Checklist

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
• Has your PR been rebased against the latest commit within the target branch (typically master)?
• Have you included steps to reproduce the behavior or problem that is being changed or addressed?
• Have you included steps or a guide to how the change may be verified and tested manually?
• Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
• Have you written or updated unit tests and or integration tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

[nickwallen]

I might be able to slim these changes down some more. I have an idea on how to do that. Working through it.

[nickwallen]

I've slimmed this down quite a bit by taking a different approach with the EnrichmentLookup and FakeEnrichmentLookup.

[nickwallen]

I have validated this in the centos6 development environment.

[nickwallen]

No longer needed per this discussion.