1 Overview

By default, Suricata doesn't log anything to disk. In this exercise we will be telling Suricata what types of logs that you would like it to create. In the following steps we will enable Suricata to log to files, turn on the TLS and DNS parsers and test that Suricata is working properly by sending test traffic through the system.

1.1 Configuring Suricata to log to disk

Configure the "logging outputs" for Suricata

# editor /etc/suricata/suricata.yaml

On line number 787 of the suricata.yaml configuration file, enable "file" logging by changing the value of the "enabled" key values set to "yes" from "no". When you have completed this step, your config file should look like the following excerpt:

  # Define your logging outputs.  If none are defined, or they are all
  # disabled you will get the default - console output.
  outputs:
  - console:
      enabled: yes
  - file:
      enabled: yes
      filename: /var/log/suricata.log
  - syslog:
      enabled: no
      facility: local5
      format: "[%i] <%d> -- "

1.2 Configuring Suricata to enable DNS and TLS logging

# editor /etc/suricata/suricata.yaml

Around line number 40 you will see the following configuration directives. Ensure that http-log, tls-log and dns-log have the "enabled" key values sent to "yes". When you have completed this step, your config file should look like the following excerpt:

  - http-log:
      enabled: yes
      filename: http.log
      append: yes
      #extended: yes     # enable this for extended logging information
      #custom: yes       # enabled the custom logging format (defined by customformat)
      #customformat: "%{%D-%H:%M:%S}t.%z %{X-Forwarded-For}i %H %m %h %u %s %B %a:%p -> %A:%P"
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'

  # a line based log of TLS handshake parameters (no alerts)
  - tls-log:
      enabled: yes  # Log TLS connections.
      filename: tls.log # File to store TLS logs.
      append: yes
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'
      #extended: yes # Log extended information like fingerprint
      certs-log-dir: certs # directory to store the certificates files

  # a line based log of DNS requests and/or replies (no alerts)
  - dns-log:
      enabled: yes
      filename: dns.log
      append: yes

1.3 Restart Suricata to apply changes

When you are finished with making changes to the suricata.yaml, issue the following command to restart Suricata:

# service suricata restart

1.4 Verifying that Suricata is logging protocol metadata

When Suricata is working correctly, you should be able to see the logs it generates in the directory: '/var/log/suricata'
In order to test Suricata, lets first initate a DNS query:

# apt-get install dnsutils
# host nsrc.org

Now check the DNS log to ensure that the query was logged:

# tail -f /var/log/suricata/dns.log

If your query was successful, you should see the following information in the log:

07/16/2015-01:18:52.555394 [**] Query TX 54ab [**] nsrc.org [**] A [**] 10.0.2.15:37770 -> 10.0.2.3:53
07/16/2015-01:18:52.555394 [**] Response TX 54ab [**] Recursion Desired [**] 10.0.2.3:53 -> 10.0.2.15:37770
07/16/2015-01:18:52.555394 [**] Response TX 54ab [**] nsrc.org [**] A [**] TTL 300 [**] 128.223.157.25 [**] 10.0.2.3:53 -> 10.0.2.15:37770
07/16/2015-01:18:52.672384 [**] Query TX f870 [**] nsrc.org [**] AAAA [**] 10.0.2.15:33718 -> 10.0.2.3:53
07/16/2015-01:18:52.672384 [**] Response TX f870 [**] Recursion Desired [**] 10.0.2.3:53 -> 10.0.2.15:33718
07/16/2015-01:18:52.672384 [**] Response TX f870 [**] nsrc.org [**] AAAA [**] TTL 300 [**] 2607:8400:2880:0004:0000:0000:80df:9d1c [**] 10.0.2.3:53 -> 10.0.2.15:33718
07/16/2015-01:18:52.854448 [**] Query TX fa53 [**] nsrc.org [**] MX [**] 10.0.2.15:37918 -> 10.0.2.3:53
07/16/2015-01:18:52.854448 [**] Response TX fa53 [**] Recursion Desired [**] 10.0.2.3:53 -> 10.0.2.15:37918
07/16/2015-01:18:52.854448 [**] Response TX fa53 [**] nsrc.org [**] MX [**] TTL 10 [**] smtp.nsrc.org [**] 10.0.2.3:53 -> 10.0.2.15:37918

1.5 Verifying that Suricata is logging signature matches

Find a rule that you want to match against in the Suricata rules directory. Reccomendation: For testing Suricata, a rule that matches against known-bad user-agent strings is a good test.

# less /etc/suricata/rules/emerging-user_agents.rules

Look for the following rule in 'emerging-user_agents.rules' if it exists in your ruleset (it does as of July 15, 2015) then continue on to the next step, if not, ask the instructor for help

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Suspicious User Agent (BlackSun)"; flow:to_server,established; content:"User-Agent|3a| BlackSun"; nocase; http_header; reference:url,www.bitdefender.com/VIRUS-1000328-en--Trojan.Pws.Wow.NCY.html; reference:url,doc.emergingthreats.net/bin/view/Main/2008983; classtype:trojan-activity; sid:2008983; rev:6;)

What this rule says is: "Any time Suricata sees the HTTP user-agent string "BlackSun" please alert me. User-agent strings are sometimes used by malware authors as an authentication token -- the command-and-control server will not issue commands to computers that make requests of it unless the correct user-agent string is specified by the client in the HTTP session. This is one way malware authors evade malware researchers. Luckily for security professionals, these user-agent strings can be very good indicators of malware presence on a system. This is why user-agent strings are included in Suricata rules.
Finally, issue traffic to google.com using the user-agent string "BlackSun"

# apt-get install curl
# curl -A "BlackSun" www.google.com

If your Suricata instance is operating correctly, you should see the following line end up in your "fast.log" in /var/log/suricata:

07/16/2015-01:32:12.275324  [**] [1:2008983:6] ET USER_AGENTS Suspicious User Agent (BlackSun) [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 10.0.2.15:49779 -> 74.125.28.99:80

2 Summary

In this exercise we learn to enable the DNS and TLS parsers for Suricata, check the logs for the protocol parsers and test out signatures from emerging threats that indicate malwares presence on a system. Suricata logs are located in: '/var/log/suricata'. The 'dns.log' and 'tls.log' are used to keep metadata extracted from network protocols, the 'fast.log' is used to keep alerts that arise from integrating and matcing against threat intelligence with Suricata.