Feeding Metadata & Third Party Log Event Information

In this installment of the Tips and Insights series, Todd Bane demonstrates how to enable the evidence collector and comm broker features on the FireEye NX appliance in order to feed in metadata and third party log event information into your Helix instance.

Hi my name is Todd Bane and I’m a Technical Initiatives Manager here at FireEye’s Deployment and Integrations team. Today I would like to demonstrate how to enable the evidence collector and comm broker features on the FireEye NX appliance in order to feed in metadata and third party log event information into your Helix instance. First we begin by logging into the command line of your local NX appliance. This may be a physical form factor appliance or a virtual instance running on a virtual hypervisor. First we issue the enable command and configure terminal command to get into the configuration route menu. We will want to ensure that the Helix mode is enabled on this NX appliance. Because this is an on premise device we will want to specify Helix mode on premises. Next we will begin to configure the tapsender portion of this feature. First we will want to log in to the Helix console and go to the operational dashboard in order to download the certificate required to authenticate to the Helix receiver. We do this by scrolling down to the bottom of the operational dashboard page to download certificate Click the link to download the certificate. Once the certificate is downloaded we will need to log in to either the CMS or the NX appliance to upload the certificate to that appliance. In order to upload the certificate we’ll want to go to settings. Navigate to the appliance. And then navigate to certificates and keys. Next we will click the add certificate keys And select the PEM formatted certificate and private key to upload to the NX appliance. We will want to make sure that the certificate name is given a name that is meaningful and relevant to the use of this certificate.

Once the files are selected you will then want to press the commit button. Do not check the box for after import activate. Now that the certificate has been uploaded we will then navigate back to our command line. We will proceed by specifying the certificate name that we just uploaded to the appliance.

Next we will want to make sure that the tapsender or evidence collector VPCIP hostname is configured correctly. If it is not already configured then we will want to manually input that information. This information can be found with a show fenet dti configuration command. Under Helix address and the DTI row you should see the hexidentifier.receiver.apps.fireeye.com as the receiver destination URL for your Helix instance. We will then configure the tapsender VPCIP with this receiver address. Next we will want to ensure that firewall teams have allowed the outbound 443 connection to this receiver.apps.fireeye.com destination. In cases where next gen firewall or application blocking is in place you will want to ensure the SSL protocol is allowed over 443. Next we will verify that the VPC destination is configured correctly. Once this is verified we can then enable the tapsender.

We can use a show tapsender status to verify the status of the tapsender feeding into Helix. We can also use a show tapsender stats in order to verify how much information is being received and EPS count by the NX appliance. This should accurately reflect in batches the amount of EPS that will feed into the Helix instance. Next we will also issue a show tapsender health command to verify that authentication to the Helix pipeline or the receiver destination was successfully authenticated. A status of connected implies a successful authentication connection. Next we will enable the comms broker in order to receive syslog or JSON formatted messages from third party devices.

First we will issue a comm broker command to configure the input based off of the format type. Syslog configuration can be either in a syslog format, CEF, LEF or XML based formatted messages. JSON formatted messages should be configured with the JSON input module type. When configuring a syslog message we will choose the interface on the NX that the information is being sent to from the third party appliance or third party data source. Most customers use the management interface ether1. And we’ll specify then a protocol either TCP or UDP in order to receive the messages. Once we have selected a protocol we will then specify the port that the NX will be listening for the syslog messages on. Standard 514 is acceptable.If you are using non-standard syslog ports this can be configured as well. Next we will enable the comm broker through the comm broker enabled command. We can then verify the status of the comm broker feature by executing a show comm broker’s status command. State enabled and running status running and supported support platform are all indications of successful execution and configuration A TCPDUMP command can also be used in this situation to verify that syslog messages are being received on the interface and on the port configured for the comm broker. In instances where JSON formatted event data is being sent to the comm broker it is recommended that the port configured on the comm broker is used with 515. This will allow JSON formatted events to be routed to the appropriate pipeline modules on the Helix back end in order to be matched against taxonomically compliant JSON formatted fields. And this concludes our demonstration for enabling the tapsender or evidence collector and comm broker feature for gathering third party log event information you and stay tuned for more FireEye tips and insightsyou and stay tuned for more FireEye tips and insights

Scroll to Top