Professional Documents
Culture Documents
(TAP)
Deployment Guide
April 28, 2014
Deployment Checklist
Before deploying TAP, you must first contact FireEye Sales to obtain the proper license
for Threat Analytics Platform (TAP). Your data sources will not be fully functional until
you obtain this license.
To contact the TAP team, including TAP Sales, e-mail to tap@fireeye.com.
For more information on TAP, see the FireEye Threat Analytics Platform page on the
FireEye website.
TAP Overview
TAP is a cloud-based application that:
l Collects and indexes database, security, network, and endpoint events from your
environment
l Compares indicators in your events against FireEye intelligence in real time and
generates alerts on hits
l Applies both FireEye-defined rules and rules that you define to event data to gen-
erate alerts
l Provides an incident workflow for tracking both events associated with alerts and
any events that you deem suspicious from investigation to remediation
l Makes events available for efficient searching and pivoting
l Provides visualizations of trending activity
TAP Architecture
Your TAP instance resides in two environments: your environment and a Virtual Private
Cloud (VPC) within Amazon World Servies (AWS). Within your environment is one or
more Communication Broker Senders that send log data to a Communications Broker
l Enter interface IP address that sender will listen on [0.0.0.0]: 0.0.0.0 (Hit
514)
l Add another?: [no] (Hit Enter to continue; to add additional
modifications as needed)
5. You should see the following messages:
l Replacing senders in init file
l tap-cbs stop/waiting
l tap-cbs start/running, process 1448
l Sender has successfully been initialized
l rm /etc/init.d/tap-cbs
l rmdir /opt/tap-cbs
Step 3. Use tcpdump to verify the Communication Broker is receiving syslog traffic from
log sources (e.g. tcpdump –ni eth1 –c 50 –s0 –A udp port 514)
Alternatively, you can verify the Communication Broker is listening and receiving log
traffic on the configured ports.
Use the Netcat utility to send traffic from another device to the Communication Broker
(e.g. echo -n "TEST TEST TEST" | nc -4u -w1 <ip address of sender> 514 )
Look for this traffic on the Communication Broker (e.g., tcpdump –ni eth1 –c 50 –s0 –A
udp port 514 )
l Each ACL should end with a default statement to deny all traffic, and log:
l Type: UDP
l Filter: Standard
Linux Configuration
Linux systems can utilize a number of different syslog tools to send logs to the Com-
munications Broker.
Rsyslog Configuration
When configuring Rsyslog for Centros and RedHat 5 and 6, be sure the fully qualified
domain name (FQDN) of the Communications Broker is registered in domain naming
server (DNS) and the server can resolve the name correctly.
To edit the Ryslog configuration:
1. Open /etc/rsyslog.conf
2. Add the following lines to the body of the file (note that in this script @ infers UDP
is used, @@ will use TCP):
“# ### begin forwarding rule ###”
# These messages will log to the Communications Broker
Auth.info @CommBroker.company.com:514
Syslog-ng Configuration
Edit the Syslog-ng Configuration for Ubuntu LTS:
1. Open /etc/syslog-ng/syslog-ng.conf
2. Define a new destination: destination d_commbroker {syslog
("10.1.1.1"transport("udp")port(514));};
3. Replace "10.1.1.1" with theIP address of the communication broker
4. Add this destination to the appropriate log definition:
log {
source(s_network); #example existing log source
source(s_bro_conn); # example existing log source
destination(d_commbroker);
}
To restart the service:
service syslog-ng restart
Splunk Configuration
There are three types of Splunk Fowarders: Universal, Heavy, and Light; the only one
that supports SYSLOG is a Heavy Forwarder.
The following links provide data on forwarding data from Splunk:
l http://docs.splunk.com/Documentation/Splunk/5.0.4/Deploy/Deployaforwarder
l http://docs.splunk.com/Documentation/Splunk/latest/Deploy/Forwarddatatothird-
partysystemsd#Forward_syslog_data
Validate that logs were being forwarded to the Comm Broker Sender by running this tcp-
dump command: tcpdump port 514 host <IP address of Splunk Server-
/Fowarder) –A
The Splunk GUI may flash a message saying that forwarding has stopped due to a spike
in event volume. The message also may say there is a lack of open files or memory. In
the event Splunk stops forwarding data and starts dropping events, do the following:
1. Modify the memory setting on the Splunk server in /etc/se-
curity/limits.conf or in /etc/security/limits.d/90-nproc.conf
Module xm_csv
Fields $date, $time, $s-sitename, $s-computername, $s-
ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port,
$cs-username, $c-ip, $cs-version, $cs(User-Agent), $cs
(Cookie), $cs(Referer), $cs-host, $sc-status, $sc-sub-
status, $sc-win32-status, $sc-bytes, $cs-bytes, $time-
taken
FieldTypes string, string, string, string, string,
string, string, string, string, string, string,
string, string, string, string, string, string,
string, string, string
Delimiter ' '
</Extension>
<Input internal>
Module im_internal
</Input>
SavePos True
InputType LineBased
Exec to_syslog_bsd();
</Input>
<Input IIS_Logs>
Module im_file
File "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\u_ex*"
SavePos TRUE
Exec to_syslog_bsd();
</Input>
<Output out>
Module om_tcp
Host 10.1.1.10
NXLog Troubleshooting
Always check the nxlog.log file for errors. This is file is found in C:\<Install_
Path>\data. If it shows anything other than the example, there is a problem with the
configuration file that must be resolved.
Verify that INFO nxlog-ce-2.7.1191 started.
You can also run a Wireshark to look at packet captures leaving the system as follows:
l Queries is checked.
DHCP Logs
DHCP logs help connect the dots from perimeter activity (such as a firewall event show-
ing a connection to a C2 server) to the inside host. As hosts are dynamically assigned
IPs via DHCP, or roaming between wireless access points, tracking who is where
becomes difficult without DHCP logs.
We recommend enabling DHCP audit logging, and sending those logs to TAP using
NXLog. An important note to remember, you must change the logging path from the
default in order to forward with NXLog.
To enable logging:
1. Find the DHCP server in the Server Manager console.
2. Expand DHCP and right click the server, and choose IPv4 Properties.
3. Under the General tab, click Enable DHCP audit logging.
4. Verify the path to the log files (note the path has been changed from c:\Win-
dows\system32\dhcp) for the Audit log file path option under the Advanced tab.
Netlogin Debug Logs
Enabling Netlogon debug logging provides detailed activity about authentication beyond
what is normally contained in security event logs. These logs can also be shipped using
NXLog. See http://support.microsoft.com/kb/109626 for more information.
IIS Logs
Internet Information Server (IIS) logs do not provide much information by default, but they
have the ability to be very verbose. We recommend you enable logging to capture import-
ant informationfor detecting malicious activity, such as the method, bytes transferred, and
other critical data. IIS logs can be sent to TAP using NXLog.
The system requirements are:
l IIS 6, 7 or 8
l A reliable NTP source
l For Log Event Destination, select Log file only or Both log file and ETW
event
l For Schedule under Log File Rollover, select Daily
SQL Events
SQL events can be written to the Windows event logs, making it easy to collect database
activity logs. For more information, see http://technet.microsoft.com/en-us/lib-
rary/cc645889.aspx.