5. Meer configuration:

Meers operations are mainly controlled by the meer.yaml file. The configuration file is split into three sections. The meer-core controls how Meer processes incoming data from EVE files. The input-plugins controls how Meer receives data. The output-plugins controls how data extracted from the EVE files is transported to a database backend. To view a full example `meer.yaml` configuration file, go to: https://github.com/quadrantsec/meer/blob/main/etc/meer.yaml

5.1. ‘core’ options

Below describes the options in the core section of the meer.yaml.

5.1.1. hostname

Texts field that is added to Suricata/Sagan EVE JSON. This short text field represents “were” the data is originating from. This is a required option. For example::

hostname: "awesome-sensor.example.com"

5.1.2. interface

This describes in what interface the data was collected. With Suricata, this might description the device network traffic is being acquired from (“etho”, “bridge0”, etc). With Sagan, this might describe log sources (“windows-logs”, “cisco-logs”, etc). This is a required option. For example::

interface: "eth0"

5.1.3. description

This is a text field that description the sensor (what it is monitoring, etc). This is typically a short sentence. For example::

description: "DMZ - web services and SQL databases".

This data is add to the Suricata or Sagan EVE data.

5.1.4. type

The type is a single text field to describe the sensor. At Quadrant Information Security, we use this field to describe the sensor function in life. For example::

type: "pie"           # PIE == Packet Inspection Engine / LAE == Log Analysis Engine

5.1.5. payload-buffer-size

The max memory to be allocate per EVE log line. This should match you Suricata or Sagan buffer size. If you EVE data is being truncated, consider increasing this. The default a `1mb of RAM::

payload-buffer-size: 1024kb  # Can end with kb, mb, gb.

5.1.6. runas

This is the user name the Meer process should “run as”. You will likely want to run Meer as the same user name that is collecting information (for example, “suricata” or “sagan”). The runas can protect your system from security flaws in Meer. Do not run as “root”. This option is required::

runas: "suricata"

5.1.7. classification

The classification option tells Meer where to find classification types. This file typically ships with Sagan, Suricata, and Snort rules. It defines a ‘classtype’ (for example, “attempt-recon”) and assigns a numeric priority to the event. This option is required::

classification: "/etc/suricata/classification.config"

5.1.8. meer_log

The meer_log is the location of the file for Meer to record errors and statistics to. The file will need to be writable by the same user specified in the runas option. If not specified, the default file location is /var/log/meer.log.::

meer_log: "/var/log/meer/meer.log"

5.1.9. lock_file

The lock_file is used to help avoid multiple Meer processes from processing the same data. The lock_file should be unique per Meer instance. The lock file contains the process ID (PID) of instance of Meer. This option is required.::

lock_file: "/var/log/meer/meer.lck"

5.1.10. input-type

This tells Meer where to acquire data from. This controls which input plugin (input-plugins) to use. This option is required.::

input-type: "file"

5.1.11. calculate-stats

When statistics (event_type “stats”) from Suricata are collected, they are represented in a accumulated manor (ie - “1000,2000,3000,4000”). While this works well for some utilities (rrdtool , librenms, etc), it doesn’t work well with others (SQL databases, etc). When this option is enabled, Meer will track and do the math to convert the statistics as a accumulated metric (ie “1000, 2000, 3000, 4000”) to time based, between “stats” metric (ie - “1000,1000,1000,1000”). Another example would be, rather than reporting Suricata has seen X number of bytes since this initial start of Suricata, X number of bytes has been seen since the last statistics where reported. This option does not process all stats but rather a small subset. They are kernel_packets, kernel_drops, errors, bytes, invalid, ipv4, ipv6, tcp and udp. When the calculate-stats option is enabled, a new JSON nest is added to the event_type stats with these aggregate statistics. ::

calculate-stats: false

5.1.12. fingerprint

The fingerprint option tells Meer to decode “fingerprint” rules and route the data differently. Fingerprint rules do not work like normal rules. The data from these rules is used to passively fingerprint systems for operating systems and types (client/server). This information can be valuable to determine if an attack might have been successful or not.

For a full explanation of our Meer handles Suricata and Sagan “fingerprinting” signatures, please watch Jeremy Groves “Passive Fingerprinting Suricata” on Youtube (https://www.youtube.com/watch?v=n5O4-iqAlVo). ::

fingerprint: disabled
fingerprint_networks: "10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12"

fingerprint_reader: enabled         # This option appends "fingerprint"
                                    # data to "alert".

fingerprint_writer: enabled         # This option detects "fingerprint"
                                    # alerts and writes them to Redis.

The fingerprint_networks are you networks. These are the IP address spaces we want to record device fingerprint data from. The fingerprint_reader tells Meer to “append” fingerprint data to alert EVE JSON. The `fingerprint_writer configures Meer to “write” fingerprint data about devices to Redis. By default, this option is disabled.

5.1.13. client_stats

This option has no affect on Suricata data. This option can be used when processing Sagan data. The client_stats option works in conjunction with the Sagan client-stats option. The basic concept is that Sagan will write out information at intervals (example log data, bytes sent from individual clients, etc). This option will read in this JSON and report it to a Redis backend. By default, this option is disabled.::

client_stats: disabled

5.1.14. oui_lookup

When Meer encounters a MAC address within an EVE file, it will lookup the vendor of the MAC address. This data is added to the EVE JSON. By default, this is disabled. ::

oui_lookup: disabled
oui_filename: "/usr/local/etc/manuf"
                                            # https://gitlab.com/wireshark/wireshark/raw/master/manuf
                                            # This file contains MAC/OUI data.

5.1.15. dns

The dns option tells Meer to perform a DNS PTR (reverse) record lookup of the IP addresses involved in an alert. This option is useful because it records the DNS in your EVE JSON at the time the event occurred. This is enabled by default. ::

dns: enabled
dns_cache: 900                              # Time in seconds / cache timeout
dns_lookup_types: "alert,ssh,http,rdp,ftp"  # The event_type to do DNS
                                            # PTR lookups for.  This can
                                            # be the event_type or "all".

When dns is enabled, Meer will internally cache records to avoid repetitive lookups. For example, if 1000 alerts come in from a single IP address, Meer will look up the DNS PTR record one time and use the cache for the other 999 times. This saves on lookup time and extra stress on the internal DNS server. If you do not want Meer to cache DNS data, simply set this option to 0. The dns_cache time is in seconds.

dns_lookup_types are Suricata event_types that DNS queries will be performed on.

5.1.16. geoip

If Meer is compiled with the --enable-geoip option, this will allow Meer to do GeoIP lookups from a Maxmind (https://maxmind.com) data. GeoIP information is stored within the EVE JSON as a new JSON nest named geoip_src and geoip_dest. This data can include country code, subdivision, City, postal code, timezone, longitude and longitude. By default, this option is disabled. ::

geoip: disabled
geoip_database: "/usr/local/share/GeoIP2/GeoLite2-City.mmdb"

The geoip_database is the location of your Maxmind database file. This is loaded when Meer is started. You can download GeoIP “Lite” databases from https://dev.maxmind.com/geoip/geolite2-free-geolocation-data

5.1.17. ndp-collector

The NDP collector (Network Data Point) is an option of distilling data from Suricata into “non-repetitive” data points. The concept is that store data into Elasticsearch, Opensearch or Zincsearch (https://github.com/zinclabs/zinc) for “quick” IOC (Indicator of Compromise) searches. Since the data is “non-repetitive”, the NDP collector only stores the minimal amount of data around an event. This option is disabled by default. We will be adding more information about this option as it comes available. ::

ndp-collector: disabled
ndp-debug: disabled
ndp-ignore-networks: "10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12"
ndp-routing: "flow, http, ssh, fileinfo, tls, dns, smb, ftp"

ndp-smb: "SMB2_COMMAND_CREATE, SMB2_COMMAND_WRITE"
ndp-smb-internal: true

ndp-ftp: "STOR, RETR, USER"

The ndp-ignore-networks should represent any public or internal network blocks you use. The NDP collector not store data about these networks as they are typically not useful for rapid IoC searches.

The ndp-routing tells Meer where to pull non-repetitive data from. Since we are storing non-repetitive data, the only options are flow, http, ssh, fileinfo, tls, dns, smb and ftp.

The ndp-smb option configures Meer to only store SMB command related to this list. Typically, to keep datasets small, we only want to record SMB2_COMMAND_CREATE and SMB2_COMMAND_WRITE. Because SMB is not typically used over the Internet, the ndp-smb-internal option configures Meer to record all internal SMB traffic. This is done because SMB is used by attackers to move laterally within a network.

The ndp-ftp option records FTP traffic but only commands related to this list.

If this option is being used, use the input-type of redis is probably the most efficient.