1. Presentation

SIGFLOW analyses all network traffic. It can generate alerts, metadata, and content based on rules. Coming from different sources, these rules must describe the characteristics of the attacks to be detected as well as being optimised to reduce false positives. Gatewatcher provides a set of rules that can be downloaded from its update platform. The following paragraphs describe the steps required to provide these rules to the GCAP SIGFLOW module through the GCENTER.

The basic configuration steps are as follows:

Managing the available rule sources
Creating rulesets from sources
Generating rulesets (important)
Applying rulesets on gcap
Advanced configuration of gcap parameters

2. GCAP Profiles

Menu: Operators > Sigflow > GCap Profiles

From this configuration interface, users will be able to apply specific policy rules. They can customise the settings from the following categories:

Detection Ruleset
Base variables
Net variables
Flow timeouts
Files rules management
BPF filter

In order to start the detection engine on the GCap probe, the user must first apply a ruleset to it. See section Sigflow/Rulesets on creating a ruleset".

2.1. Detection Rulesets

Menu: Operators > Sigflow > GCAP Profiles

The Detection Rulesets section enables applying previously created SIGFLOW Rulesets to GCAPs paired on the GCENTER. It is also possible to configure the codebreaker module for the GCAP that includes enabling or disabling shellcode and powershell detection separately.

Note

It is necessary to generate rules for a ruleset before applying it to GCAPs. Failure to do so will result in no rules being applied.

Note

Codebreaker is not configurable via the Detection Rulesets menu with the CIE license.

**The GCAP Detection Rulesets menu enables three configuration options

Single tenant:
- Assign a ruleset for all GCAP monitoring interfaces;
- Enable/disable codebreaker for all GCAP monitoring interfaces.
The multi-tenant per interface:
- Assign a ruleset per GCAP monitoring interface;
- Enable/disable codebreaker per GCAP monitoring interface.
Multi-tenant by vlan:
- Assign one ruleset per vlan;
- Assign a ruleset for the default vlan for those vlans not created via the interface;
- Enable/disable codebreaker per vlan;
- Enable/disable codebreaker for the default vlan for those vlans not created via the interface;

Note

These configuration options are exclusive. This means that it will not be possible to apply a single tenant and multi-tenant per vlan configuration at the same time.

2.1.1. Single-tenant

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

Single-tenant configuration:

Go to the Single-tenant tab;
Select a ruleset to apply to all interfaces;
Enable or disable shellcode detection for all interfaces;
Enable or disable powershell detection for all interfaces;
Apply the configuration by clicking the "save" button.

2.1.2. Multi-tenant by interface

The multi-tenant by interface enables applying a single-tenant configuration for each of the GCAP interfaces, thus having a different supervision per interface. Indeed, it is possible to apply a different SIGFLOW ruleset, as well as to configure codebreaker for each of the GCAP interfaces.

Note

It is advisable to optimise the SIGFLOW ruleset in advance before choosing this configuration option. The rules must be adapted to the monitored environment.

Note

It is necessary to verify whether multiple monitoring interfaces are enabled on the GCAP prior to applying a multi-tenant by interface configuration.

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

Note

Only activated monitoring interfaces appear in the GCENTER interface.

Configuring multi-tenant by interface:

Go to the Multi-tenant by interface tab;
Select a ruleset to apply for each interface;
Enable or disable shellcode detection for each interface;
Enable or disable powershells detection for each interface;
Apply the configuration by clicking the "save" button.

Configuration example:

interface mon0:
- Ruleset named "Test-mon0",
- Enabling shellcode/powershell detection.
interface mon2:
- Ruleset named "Test-mon2",
- Disable shellcode/powershell detection.

2.1.3. Multi-tenant by vlan

The multi-tenant by vlan enables a configuration to be applied for each vlan previously created in the interface and to have distinct monitoring on different networks. Thus, it is possible to apply a SIGFLOW ruleset as well as to configure codebreaker independently for each vlan. A vlan named "default" is created as standard in the interface. It enables a SIGFLOW ruleset to be applied and codebreaker to be configured for all vlans not explicitly specified in the interface.

Note

It is advisable to optimise the SIGFLOW ruleset in advance before choosing this configuration option. The rules must be adapted to the monitored environment.

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

Configuring multi-tenant by vlan:

Go to the Multi-tenant by vlan tab;
Select a ruleset to apply to the default vlan;
Enable or disable shellcode detection for the default vlan;
Enable or disable powershell detection for vlan "default";
Create as many vlans as necessary via the "Add" button;
The vlan name must match the vlan number between 0 and 4096;
Then select a ruleset to apply to each vlan;
Enable or disable shellcode detection for each vlan;
Enable or disable powershell detection for each vlan;
Apply the configuration by clicking the "save" button.

Configuration example:

vlan "default":
- Ruleset named "Test-default",
- Enabling shellcode/powershell detection.
vlan "110":
- Ruleset named "Test-vlan110",
- Disable shellcode/powershell detection.

2.2. Base variables

Menu: Operators > Sigflow > GCAP Profiles

The Base variables section enable the operator to adjust the capture parameters of the probe using the advanced Suricata functions configurable from the GCENTER. Changes to this configuration have an impact on the alerts sent from the GCAP probe to the GCENTER. Enabling certain options will enable the sending of alerts, anomalies, metadata, file information, and protocol-specific records.

Alerts are records of events triggered by the matching of a rule with network traffic. An alert will be created with associated metadata, such as the application layer record (HTTP, DNS, etc).

The menu is divided into three sections:

General
Stream
Parsing

2.2.1. Base Variables - General

The Base Variables - General tab enables configuring the advanced settings of the GCAP probe (Suricata).

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

The default values for variables on the general tab:

Variables	Values
file_resend_interval	86400s
files_hash	['md5']
flow_memcap	17179869184 Bytes
flow_prealloc	1048576
ftp_memcap	10485760 Bytes
http_body	Disabled
http_body_printable	Disabled
max_pending_packets	4096
packet	Enabled
payload	Enabled
payload_buffer_size	4096 Bytes
payload_printable	Enabled
smb_stream_depth	10485760 Bytes
xff_deployment	reverse
xff_enable	Enabled
xff_header	X-Forwarded-For
xff_mode	extra-data

List of variables on the General tab:

File resend interval (seconds):** time frame in seconds in which, if an identical file is sighted on the network, it will not be resent to the GCENTER by the GCAP. Only the metadata will be sent with the Replica field set to True. After this time interval, if the same file is seen on the network, it will be sent back to the GCENTER.
Max pending packets: Number of simultaneous packets the SURICATA engine can handle. This can range from one packet to tens of thousands of packets. This parameter will have an impact on performance and memory (RAM) usage. A high number of packets being processed enables better performance, more memory to be used, and vice versa. Choosing a low number of packets being processed, while having multiple CPU cores, may result in not using the full capacity of the probe. Example: using a single core while having three packets waiting to be processed.
Enable XFF: Enable the HTTP X-Forwarded-For header management by adding a new field or by overwriting the source or destination IP address (depending on the direction of the flow) with the IP indicated in this header. The behaviour, either adding a field or overwriting, is handled by the XFF mode directive. This directive is helpful when processing flows behind a reverse proxy for example.
XFF mode: Expected behaviour when XFF is activated. Two types of operating modes are available, extra-data or overwrite. Note that in 'overwrite' mode, if the IP address reported in the HTTP X-Forwarded-For header is a different version of the received packet, then it will switch to 'extra-data' mode.
XFF deployment: XFF deployment type. Two types of deployment are available: reverse or forward. In a reverse deployment, the IP address used is the last one, while in a forward deployment, the IP address used is the first one.
Xff header: This is the name of the HTTP header in which the actual IP address is present. If more than one IP address is present, the last IP address will be the one used.
Payload: Adds a field containing the base64 encoded payload of a flow triggering an alert.
Payload buffer size: maximum size of the payload buffer to be added to the alert.
Payload printable: Adds a field containing the (Payload) in ASCII (so-called 'human') format.
Packet: dump of the captured base64 encoded package.
HTTP body: Adds a field containing the body of base64 encoded HTTP requests. This parameter requires metadata to work.
HTTP body printable: Adds a field containing the body of HTTP requests in ASCII (so-called 'human') format. This parameter requires metadata to work.
Flow memcap: maximum allocation for byte flows.
Flow prealloc: initial flow allocation.
FTP memcap (B): 'maximum allocation for byte flows.
SMB Stream Depth (B): The size of the files that can be restored and saved depends on the value in megabytes. Beyond this value, no reconstruction will be undertaken. If this value is reached, the file may be truncated and not entirely stored. This implies that after this value, the SMB session will no longer be tracked. Additionally, negative values disable the option. Setting this value to 0 enables any file size to be stored.
Files hash: Enables selecting the hash function for rebuilt files (md5, sha1, and sha256). By default, md5 is selected. The sha256 hash will in all cases be added by the [Malcore] module (malcore.html#presentation).

2.2.2. Base Variables - Stream

Caution

Changing the settings in this section may cause the TRACKWATCH solution to malfunction. This section is reserved for support staff and advanced users.

Only the "file_store_stream_depth_mb" variable can be modified, never exceeding 100 MB.

The Base Variables - Stream tab enables configuring the file reconstruction parameters as well as the Stream-engine module of the GCAP probe (Suricata). The Stream-engine module of the probe enables monitoring the TCP connections.

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

The engine consists of two parts:

Stream-tracking engine: Enables tracking the TCP connection status;
Reassembly-engine: Reassembles the flow for analysis by Suricata.

The default values for variables on the stream tab:

Variables	Values
file_store_stream_depth_enable	Enabled
file_store_stream_depth_mb	10 MegaBytes
stream_memcap_b	32000000000 Bytes
stream_prealloc_sessions	1000000
stream_reassembly_depth_mb	10 MegaBytes
stream_reassembly_memcap_b	16000000000 Bytes
stream_reassembly_randomize_chunk_size	Enabled
stream_reassembly_toclient_chunk_size_b	2560 Bytes
stream_reassembly_toserver_chunk_size_b	2560 Bytes

List of variables on the Stream tab:

Enable File-Store stream depth: Enables control of the stored file size.
File-store stream depth (Mb): Sets the maximum size of files that can be restored and saved in megabytes. If this value is reached, the file may be truncated and not entirely stored. This implies that after this value, the HTTP session will no longer be tracked. A negative value disables the option. A value of 0 enables any file size to be stored. If this option is not enabled, then the value of 'Stream reassembly depth (Mb)' will be taken into account.
Stream memcap (B): This value is the maximum value in bytes allocated to TCP session tracking. In order to avoid a lack of resources, a memcap can be used to restrict the memory used.
Stream Prealloc sessions: This is the amount of sessions the SURICATA engine must hold in memory. This engine works independently of packet processing. It has a management thread that sets this value inside the memcap to allocate memory. The option enables SURICATA to avoid being overloaded by the fast creation of sessions. It instructs it to keep a certain number of sessions ready in memory. It specifies the number of elements to be pre-allocated when the software boots. This reduces the cost of in-running allocations at the expense of the software's initial memory usage.
Stream reassembly memcap (B) The stream reassembly engine must retain segments of data in memory in order to rebuild it. To avoid resource constraints, a memcap is used to limit the memory used. This option is the maximum amount of bytes the flow engine can use to restore a file.
Enable the randomizable of chunks size: The purpose of this setting is to avoid making chunk recovery too predictable. For this purpose, their size will be modified by a random factor that will be added.
Stream reassembly depth (Mb)** This is the size of the network flow in megabytes. The act of reassembling a data flow is a very important operation that can be controlled using the 'depth' concept. The default value is a parameter that can be overridden by the protocol analysers performing the file extraction. The inspection will be ignored if this value is reached for a particular flow. Setting this value to 0 enables any flow size to be stored.
Stream reassembly to server chunk size (B) The reconstruction of a data stream is carried out in chunks. The size of these chunks is to be set in this field so that the flow is inspected and rebuilt using this value.
Stream reassembly to client chunk size (B) The reconstruction of a data stream is carried out in chunks. The size of these chunks is to be set in this field so that the flow is inspected and rebuilt according to it.

2.2.3. Base Variables - Parsing

The Base Variables - Parsing tab enables configuring the parsing and logging of protocols used by the GCAP probe. Protocols that can be parsed and logged are present in the GCenter interface. In the event a GCAP probe is one version ahead of the GCenter, it is possible that some protocols have been added.

This is discussed in more detail in the [GCAP] documentation (https://docs.gatewatcher.com/gcap.html) in the section Detection Engine > 3. Selecting the protocols being analysed.

Terminology for parsing and logging:

Parsing consists of enabling SIGFLOW signature detection for a given protocol. Indeed, if the latter is activated for a protocol, then the flow identified by a signature will raise a SIGFLOW alert in the Kibana dashboard.
The logging consists in enabling the generation of metadata for a given protocol. Indeed, if the latter is activated for a protocol, then each observed session will raise an alert for that protocol in the Kibana dashboard.

Note

The protocols' default settings vary depending on the GCAP profile used.

Note

Changes to this tab require the GCAP configuration to be backed up and implemented via the save and apply button.

Here is the list of protocols that can be configured with the parsing option:

dcerpc
dnp3
dns_udp
dns_tcp
ftp
http
modbus
smb
smtp
ssh
tls
dhcp
ikev2
krb5
nfs
ntp
tftp

Here is the list of protocols that can be configured with the logging option:

http
dns_udp
dns_tcp
tls
smtp
smb
ssh
netflow
dnp3
ftp
dhcp
ikev2
krb5
nfs
tftp

Here is the default configuration of the parsing option for each protocol according to the profile used:

Protocols	Minimal	Balanced	LPM	Paranoid	Intuitio
dcerpc	Disabled	Disabled	Disabled	Enabled	Disabled
dnp3	Disabled	Disabled	Disabled	Enabled	Disabled
dns_udp	Disabled	Enabled	Enabled	Enabled	Enabled
dns_tcp	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Disabled	Enabled	Enabled	Enabled	Enabled
http	Enabled	Enabled	Enabled	Enabled	Enabled
modbus	Disabled	Disabled	Disabled	Enabled	Disabled
smb	Disabled	Enabled	Disabled	Enabled	Enabled
smtp	Enabled	Enabled	Enabled	Enabled	Enabled
ssh	Disabled	Enabled	Disabled	Enabled	Enabled
tls	Disabled	Enabled	Enabled	Enabled	Enabled
dhcp	Disabled	Enabled	Disabled	Enabled	Enabled
ikev2	Disabled	Disabled	Disabled	Enabled	Disabled
krb5	Disabled	Enabled	Disabled	Enabled	Enabled
nfs	Disabled	Enabled	Disabled	Enabled	Enabled
ntp	Disabled	Enabled	Disabled	Enabled	Disabled
tftp	Disabled	Enabled	Disabled	Enabled	Enabled

Here is the default configuration of the logging option for each protocol according to the profile used:

Protocols	Minimal	Balanced	LPM	Paranoid	Intuitio
http	Disabled	Enabled	Enabled	Enabled	Enabled
dns_udp	Disabled	Enabled	Enabled	Enabled	Enabled
dns_tcp	Disabled	Enabled	Enabled	Enabled	Enabled
tls	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Disabled	Enabled	Enabled	Enabled	Enabled
smb	Disabled	Enabled	Disabled	Enabled	Enabled
ssh	Disabled	Enabled	Disabled	Enabled	Enabled
netflow	Disabled	Disabled	Disabled	Enabled	Disabled
dnp3	Disabled	Disabled	Disabled	Enabled	Disabled
ftp	Disabled	Enabled	Enabled	Enabled	Enabled
dhcp	Disabled	Enabled	Disabled	Enabled	Enabled
ikev2	Disabled	Disabled	Disabled	Enabled	Disabled
krb5	Disabled	Enabled	Disabled	Enabled	Enabled
nfs	Disabled	Enabled	Disabled	Enabled	Enabled
tftp	Disabled	Enabled	Disabled	Enabled	Enabled

In addition to these protocols, it is also possible to generate NetFlow data.

Warning

Enabling NetFlow data generation will create a great deal of metadata

2.3. Net variables

Menu: Operators > Sigflow > GCAP Profiles

The Net variables section enables the operator to define the network variables used in the sigflow rules.

note:: Changes to this section require the GCAP configuration to be backed up and implemented via the save and apply button.

In the structure of a SIGFLOW rule, just after 'alert' and the protocol keyword, it is possible to use variables that will enable defining groups of IP addresses.

In the following example:

 
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:”GPL SCAN NULL”; flow:stateless; ack:0; \
flags:0; seq:0; reference:arachnids,4; classtype:attempted-recon; sid:2100623; rev:7;)

These flows must go from $HOME_NET to $EXTERNAL_NET.

The first part $HOME_NET is the source, the second $EXTERNAL_NET is the destination. With the source and destination, you specify the origin of the traffic and the location of the traffic, respectively. You can assign IP addresses (IPv4 and IPv6 are supported) and IP ranges. These parameters will be used instead of variables in the detection rules.

This section enables you to define the contents of these variables.

To implement these changes, it is necessary to click on the Save and Apply button.

The rule adapts to the needs. It can change depending on the parameter selected in the drop-down menu of each environment. The 'list', 'default (equal to HOME_NET)' and 'exclude (opposite of HOME_NET)' options respectively enable the action of the rule to be defined in relation to a group of addresses, in relation to the addresses specified in the HOME_NET environment, or in relation to all the addresses not part of the HOME_NET environment.

It is not necessary to define an address for each of the existing variables. By default, if nothing is specified, this is equivalent to applying the rule to all traffic.

The default configuration used:

Variables	Values
home_net	[]
external_net	[]
http_servers	default
smtp_servers	default
sql_servers	default
dns_servers	default
telnet_servers	default
aim_servers	default
dnp3_servers	default
dnp3_clients	default
modbus_servers	default
modbus_clients	default
enip_servers	default
enip_clients	default
dnp3_server	default
dnp3_client	default
modbus_server	default
modbus_client	default
enip_server	default
enip_client	default

2.4. Flow timeouts

Menu: Operators > Sigflow > GCAP Profiles

Caution

Changing the settings in this section may cause the TRACKWATCH solution to malfunction. This section is reserved for support staff and advanced users.

The Flow timeouts section enables configuring the time in seconds that Suricata retains a flow in memory depending on its status. The udp, tcp, and icmp protocols are configurable.

Note

Changes to this section require the GCAP configuration to be backed up and implemented via the save and apply button.

The default configuration used depending on the protocol (all values are in seconds):

protocol	new	established	closed	emergency_new	emergency_established	emergency_closed
udp	30	300	-	10	100	-
tcp	30	300	0	10	100	0
icmp	30	300	-	10	100	-
default	30	300	-	10	100	-

For each protocol, there are different statuses in which a flow can be found:

TCP protocol:
- New: The period of time during which the connection is established. This field is the time in seconds after the last activity of this flow in this status type.
- Established: The period of time during which the data transfer is taking place. This field is the time in seconds after the last activity of this flow in this status type.
- Closed: The time period during which the connection is terminated. This field is the time in seconds after the last activity of this flow in this status type.
UDP and ICMP protocols:
- New: The status during which packets are sent from a single direction. This field is the time in seconds after the last activity of this flow in this status type.
- Established: The status during which packets are sent in both directions. This field is the time in seconds after the last activity of this flow in this status type.

**Emergency_new', 'Emergency_established' and 'Emergency_closed' are the emergency modes for the three states of TCP, UDP, and ICMP.

2.5. Files rules management

Menu: Operators > Sigflow > GCAP Profiles

The Files rules management section enables configuring the file types that the probe will retrieve for a given protocol. The supported protocols are: HTTP, SMTP, SMB, NFS, and FTP. Files are extracted and then saved to disk with metadata. This includes information such as timestamp, source/destination IP address, protocol, source/destination port, size, and md5sum, etc. File extraction works in parallel with the SIGFLOW signatures defined for these same protocols. Each line in the Files rules management section corresponds to an extraction rule for a file type.

Note

Too many file extraction rules can have a significant impact on the performance of the probe.

Note

Changes to this section require the GCAP configuration to be backed up and implemented via the save and apply button.

Here is the list of fields that can be configured for an entry in the Files rules management: section

Protocol: Enables selecting the protocol for which the file will be extracted from among: HTTP, SMTP, SMB, NFS, and FTP.
Type: Enables defining the way suricata recognises the file:
- extension: Corresponds to the file extension.
- filemagic: Corresponds to the type of extracted file. The file command under linux enables obtaining this information:

shell
xxx@debian:~$ file ~/Téléchargements/xxx.exe 
/home/xxx/Téléchargements/xxx.exe: PE32 executable (console) Intel 80386, for MS Windows

Value: The identifier of the file that will be rebuilt according to the previously configured type:
- Type extension:
  - Fichier javascript: js,
  - Windows executable file: exe.
- filemagic type:
  - Javascript file: Javascript,
  - Windows executable file: PE32 executable.
Enable** and Delete are the tick boxes for activating and removing the file extraction rule respectively.

The rules applied depending on the GCAP profile used:

Protocols	Values	Minimal	Balanced	LPM	Paranoid	Intuitio
http	Microsoft Excel	Disabled	Enabled	Enabled	Enabled	Enabled
http	Microsoft Word	Disabled	Enabled	Enabled	Enabled	Enabled
http	Microsoft PowerPoint	Disabled	Enabled	Enabled	Enabled	Enabled
http	Composite Document File V2	Disabled	Enabled	Enabled	Enabled	Enabled
http	Microsoft Office Document	Disabled	Enabled	Enabled	Enabled	Enabled
http	Microsoft OOXML	Disabled	Enabled	Enabled	Enabled	Enabled
http	7-zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
http	PDF document	Disabled	Enabled	Enabled	Enabled	Enabled
http	ELF	Disabled	Enabled	Enabled	Enabled	Enabled
http	Microsoft Cabinet archive data	Disabled	Enabled	Enabled	Enabled	Enabled
http	PE32 executable (DLL)	Disabled	Enabled	Enabled	Enabled	Enabled
http	PE32 executable	Disabled	Enabled	Enabled	Enabled	Enabled
http	gzip compressed data	Disabled	Enabled	Enabled	Enabled	Enabled
http	RAR archive data	Disabled	Enabled	Enabled	Enabled	Enabled
http	Zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
http	POSIX tar archive	Disabled	Enabled	Enabled	Enabled	Enabled
http	DOS batch	Disabled	Enabled	Enabled	Enabled	Enabled
http	MS-DOS executable	Disabled	Enabled	Enabled	Enabled	Enabled
http	Java archive data	Disabled	Enabled	Enabled	Enabled	Enabled
http	Macromedia Flash	Disabled	Enabled	Enabled	Enabled	Enabled
http	OS/2 REXX batch file	Disabled	Enabled	Enabled	Enabled	Enabled
http	COM executable	Disabled	Enabled	Enabled	Enabled	Enabled
http	Node.js script text	Disabled	Enabled	Enabled	Enabled	Enabled
http	MS Windows shortcut	Disabled	Enabled	Enabled	Enabled	Enabled
http	PE32+ executable	Disabled	Enabled	Enabled	Enabled	Enabled
http	OpenDocument	Disabled	Enabled	Enabled	Enabled	Enabled
http	Mach-O	Disabled	Enabled	Enabled	Enabled	Enabled
http	Javascript	Disabled	Enabled	Disabled	Enabled	Enabled
smtp	Microsoft Excel	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Microsoft Word	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Microsoft PowerPoint	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Composite Document File V2	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Microsoft Office Document	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Microsoft OOXML	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	7-zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	PDF document	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	ELF	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Microsoft Cabinet archive data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	PE32 executable (DLL)	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	PE32 executable	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	gzip compressed data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	RAR archive data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	POSIX tar archive	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	DOS batch	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	MS-DOS executable	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Java archive data	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Macromedia Flash	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	OS/2 REXX batch file	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	COM executable	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Node.js script text	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	MS Windows shortcut	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	PE32+ executable	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	OpenDocument	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Mach-O	Disabled	Enabled	Enabled	Enabled	Enabled
smtp	Javascript	Disabled	Enabled	Disabled	Enabled	Enabled
ftp	Microsoft Excel	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Microsoft Word	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Microsoft PowerPoint	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Composite Document File V2	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Microsoft Office Document	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Microsoft OOXML	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	7-zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	PDF document	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	ELF	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Microsoft Cabinet archive data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	PE32 executable (DLL)	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	PE32 executable	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	gzip compressed data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	RAR archive data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Zip archive data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	POSIX tar archive	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	DOS batch	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	MS-DOS executable	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Java archive data	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Macromedia Flash	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	OS/2 REXX batch file	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	COM executable	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Node.js script text	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	MS Windows shortcut	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	PE32+ executable	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	OpenDocument	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Mach-O	Disabled	Enabled	Enabled	Enabled	Enabled
ftp	Javascript	Disabled	Enabled	Disabled	Enabled	Enabled
nfs	Microsoft Excel	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Microsoft Word	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Microsoft PowerPoint	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Composite Document File V2	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Microsoft Office Document	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Microsoft OOXML	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	7-zip archive data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	PDF document	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	ELF	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Microsoft Cabinet archive data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	PE32 executable (DLL)	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	PE32 executable	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	gzip compressed data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	RAR archive data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Zip archive data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	POSIX tar archive	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	DOS batch	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	MS-DOS executable	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Java archive data	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Macromedia Flash	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	OS/2 REXX batch file	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	COM executable	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Node.js script text	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	MS Windows shortcut	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	PE32+ executable	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	OpenDocument	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Mach-O	Disabled	Disabled	Disabled	Enabled	Enabled
nfs	Javascript	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft Excel	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft Word	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft PowerPoint	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Composite Document File V2	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft Office Document	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft OOXML	Disabled	Disabled	Disabled	Enabled	Enabled
smb	7-zip archive data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	PDF document	Disabled	Disabled	Disabled	Enabled	Enabled
smb	ELF	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Microsoft Cabinet archive data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	PE32 executable (DLL)	Disabled	Disabled	Disabled	Enabled	Enabled
smb	PE32 executable	Disabled	Disabled	Disabled	Enabled	Enabled
smb	gzip compressed data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	RAR archive data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Zip archive data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	POSIX tar archive	Disabled	Disabled	Disabled	Enabled	Enabled
smb	DOS batch	Disabled	Disabled	Disabled	Enabled	Enabled
smb	MS-DOS executable	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Java archive data	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Macromedia Flash	Disabled	Disabled	Disabled	Enabled	Enabled
smb	OS/2 REXX batch file	Disabled	Disabled	Disabled	Enabled	Enabled
smb	COM executable	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Node.js script text	Disabled	Disabled	Disabled	Enabled	Enabled
smb	MS Windows shortcut	Disabled	Disabled	Disabled	Enabled	Enabled
smb	PE32+ executable	Disabled	Disabled	Disabled	Enabled	Enabled
smb	OpenDocument	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Mach-O	Disabled	Disabled	Disabled	Enabled	Enabled
smb	Javascript	Disabled	Disabled	Disabled	Enabled	Enabled

2.6. Packet filtering

Menu: Operators > Sigflow > GCAP Profiles

Packet filtering enables the operator to adjust the capture parameters of the detection probe using Sigflow's advanced functions.

The purpose of this feature is to act directly on the TRACKWATCH capture device by modifying the packet acquisition method using Barkeley Packet Filter (BPF). Traffic will therefore be ignored for a given VLAN ID in the 'Dropped VLAN Id' field.

The default VLAN number is set on the GCENTER web interface in 'Default VLAN'. By default, this value is 1. Once the VLAN is set, a window appears allowing the operator to add network information about the traffic they want to remove from their notifications.

The operator can remove a filter rule via the Delete box. The changes are recorded when the form is validated by clicking on the Save button. However, in order to implement them it will be necessary to click on the Save and Apply button on the configuration page.

3. Rules management

The signatures of the Sigflow engine are structured in the following way:

A list of sources providing signatures
A list of signatures capable of adapting to the needs of the environment to be monitored
A list of Ruleset enabling signatures to be linked to their sources and a GCAP

3.1. Sources

Menu: Operators > Sigflow > Sources

Sources enable reporting on the locations where signatures are made available.

Once downloaded and unpacked, the rules need to be added to the GCENTER interface.

Once the rules are added, the operator can directly assign this source to different Rulesets

Displaying a custom rule is done from the 'View' tab in Add custom source:

These sources update automatically in the case of public / HTTP sources if the GCENTER is connected to the internet. Otherwise, a manual update can be done on this interface in order to ensure that the latest signatures are available.

Updating signatures and checking the history of changes is possible:

3.2. Rulesets

Menu: Operators > Sigflow > Rulesets

Subsequently, a 'Ruleset' must be assigned to the previously added source. The creation of the Ruleset is mandatory in order for the GCAP probe to analyse the network flow and issue alerts if the signatures match.

Modifications can be made to the rules in order to adapt a public rule to specific information systems or to a particular need.

The following changes will be applied to all categories of the Ruleset.

ACTION:

Determines the action to be applied to the created Ruleset.

Filestore: If a ruleset matches and contains a signature, the packet will be treated and stored like any other packet.

Reject: If the packet is rejected, Sigflow issues an alert for both reset packets (TCP) and ICMP error packets.

Drop: If it finds a matching rule containing the signature, it stops immediately. The packet will no longer be sent and an alert will be issued.

Bypass: If a rule matches and contains a 'bypass', Sigflow will stop scanning the packet and skip to the end of all rules. This will only be for the current packet.

LATERAL:

Signatures are often written with the variables $EXTERNAL\NET and $HOME\NET. This means that they will not match if both sides of a flow are in the $HOME_NET. Thus, lateral movements are not detected. This transformation changes $EXTERNAL_NET into any other variable in order to detect lateral movements.

The option can assume three values:

No: the replacement is not performed

Yes: $EXTERNAL_NET is replaced by whatever IP (any)

Auto: substitution is made if the signature checks certain properties

TARGET:

The keyword 'target' can be used to indicate which side of a flow triggering a signature is the target. If this key is present, related events are enhanced to contain the source and target of the attack.

The option can assume four values:

Auto: an algorithm is used to determine the target if one is present

Destination: the target is the receiving IP

Source: the target is the originating IP

None: no transformation is performed

'Add' to validate the insertion of the ruleset.

3.2.1. Optimisation of rulesets

As with the sources, the ruleset can update itself at any time. It thus updates all its signatures while proposing a differential of the operated changes:

A Ruleset can be edited to allow the operator to make changes to the sources, categories, or rules in the Ruleset.

ACTION EDIT SOURCES:

This option is used to manually enable or disable the action of a source on a Ruleset.

Once unticked, the signatures will no longer be matched by particular flows and no longer raise an alert on the interface.

ACTION EDIT CATEGORIES:

This option is used to manually enable or disable the action of a category on a Ruleset.

Once unticked, the signatures will no longer be matched by particular flows and no longer raise an alert on the interface.

It is possible to deactivate a signature related to a Ruleset directly from the SIGFLOW interface. Deactivating a rule does not lead to its permanent deletion.

The administrator may decide to duplicate the Ruleset in order to assign it to another GCAP probe, for example, depending on the network flows that are in transit. The Ruleset is specific. It must be optimised according to the probe to which it will be assigned.

ACTION COPY RULESET:

This option is used to duplicate the Ruleset. The copy will take into account the sources associated with the Ruleset.

ACTION DELETE RULESET:

The deletion of the Ruleset is irreversible. However, it will not cause the deletion of the sources and signatures that were linked to the Ruleset.

Other viewing options are available via the SIGFLOW interface. The DISPLAY section provides an overview of the categories (via Show structure) and rules (via Show rules). Moreover, thanks to this section, an export of the entire SIGFLOW configuration is possible, taking into account the Ruleset, sources, thresholds, and suppressions created.

3.3. Changing signatures

Signatures and their categories are the common thread between a source and a ruleset. It is possible to directly modify the operation of a signature from the GCenter interface.

The signatures and their categories can be accessed from a Ruleset by clicking on the View button of the Ruleset and then the category.

Depending on the alerts arriving at the interface, it is possible to be quite specific about the type or even the number of notifications. The rule can be enabled or disabled within the Ruleset.

By clicking on the "Edit Rule" link it is possible to generate rules to limit or suppress certain alerts. There are Suppress Rules that remove an alert based on the source or destination IP address and Threshold Rules that limit the number of alerts to be displayed.

THRESHOLD:

This option is used to program a restriction of alerts above a set limit.

For a threshold, there are three types of rules:

Threshold: This type can be used to set a minimum limit for a rule before alerts are generated. A threshold setting of N indicates that the nth time the rule matches, an alert is triggered.

Limit: This type can be used to ensure that it does not overwhelm with alerts. If set to N, it will alert a maximum of N times.

Both: This type is a composite of the "threshold" and "limit" types. It applies both thresholding and limiting. This alert will only generate N alerts if, within X minutes.

Then, it is necessary to:

Define whether the alert will be based on the source or destination IP
Specify the maximum number of alerts generated for the given period
Define the period in seconds to generate the alert

The created rules are available in the Ruleset page along with the format of the new rule.

SUPPRESS:

This option provides for the removal of an alert in relation to a given IP address or network.

Multiple IPs can be added separated by ' ,'.

After selecting Suppress Rules:

Choose the Ruleset to be assigned
Choose whether the alert's suppression will be based on the source or the destination.
Define the IP relevant to this rule. (in CIDR format)

The rule is available on the Ruleset page in question:

By clicking on the ID of the suppress rule it can be edited or deleted.

3.3.1. Definition of signatures

All the signatures present in the sources contain references leading to blogs, CVEs, and websites... accessible from the interface. To better understand how a signature works, here is an example of a rule:

In most cases, a rule, a signature is composed of: an action, the header, and rule options. For example:

The following protocols can be the subject of a rule:

In the signature, you can assign IP addresses, both IPv4 and IPv6, combined as well as separate. Both sources and destinations of the signature are affected.

Furthermore, it is possible to define variables such as $HOME_NET or $EXTERNAL_NET to which the IPs are to be defined . These variables are used to increase the accuracy of the alerts provided by the signatures.

The following syntax can be used to specify the addresses:

Similarly, the following syntax can be used to specify ports:

Two directions can be specified to indicate the direction of the flow:

3.4. Generating rulesets

Important

As long as the rulesets have not been generated after modifications, no configuration will be deployed.

Once the configuration of the sources, rulesets, and any modifications are completed, it is necessary to generate the configuration for the probes and implement it. This is accomplished by using the "Generate Ruleset" action, which will freeze the status of the Ruleset and take into account all modifications.

3.5. Secret Local Rule

It is also possible to define certain rules locally on a GCAP probe that will intentionally not appear in the GCENTER interface.

This may occur in the following instances:

Making signatures confidential without the GCENTER operators being able to see them, according to a 'need to know' concept.
Modify the local signatures of probes in complex cases.
If the GCENTER is assigned to a third party and the third party cannot handle markers or signatures of a certain level.

This is discussed in more detail in the [GCAP documentation] (https://docs.gatewatcher.com/gcap.html) in the section `Detection Engine > 7. Adding secret rules locally*".

4. Detection

4.1. SmartMap

Menu: Operators > SmartMap

The SmartMap enables real-time visualisation of attacks and traffic. This allows for intuitive and visual detection of unusual or particularly heavy traffic.

In order to display the information on the map, the SmartMap requires geolocation data on the alerts. The latter will therefore need to be activated from the configuration section by an administrator.

4.2. Kibana Dashboard

Menu: Operators > Dashboards

All the information analysed by the Sigflow module is stored in order for the operators to be able to carry out an analysis in the most efficient way possible.

Thus, various dashboards are made available by default.

The information from the Sigflow module can be found in the Tactical *dashboard. This provides a global view of the threats, including those identified by Sigflow.

More specific data for this module can also be found in the Sigflow *dashboard.

As always, it is possible to obtain the full details of the alerts by switching to the Messages view

The fields present are those detailed below in the section Generated events

Finally, this module also enriches the observed traffic with the metadata that were analysed according to the configuration made on the GCAP profile

5. Generated events

For suricata, and therefore Sigflow, the fields created depend on the observed flow.

5.1. Document type "alert"

List of fields present in all alerts with event_type == alert:

@timestamp
@version
alert.action
alert.category
alert.gid
alert.rev
alert.severity
alert.signature
alert.signature_id
dest_ip
event_type
flow.bytes_toclient
flow.bytes_toserver
flow.pkts_toclient
flow.pkts_toserver
flow.start
flow_id
gcap
GCenter
host
packet
packet_info.linktype
payload_printable
proto
severity
src_ip
stream
timestamp_analyzed
timestamp_detected
type
uuid

List of protocols compatible with parsing (app_proto field):

dcerpc
dhcp
dnp3
dns
ftp
http
ikev2
krb5
modbus
nfs
ntp
smb,
smtp
ssh
tftp
tls

If a protocol changes midstream, for example if SMTP is upgraded to TLS via STARTTLS, or if the protocols used are not the same in both directions of the flow, the following fields may appear:

app_proto_tc (to client)
app_proto_ts (to server)
app_proto_orig

Summary table of fields that do not depend on the protocols:

Fields	Required	Suricata keyword	Description
alert.action	Yes	alert, drop, reject, pass	Allowed if the alert or pass action is used; blocked if the drop or reject action is used.
alert.category	Yes	classtype	Description of the alert's classification.
alert.gid	Yes	gid	Identifier of an alert group.
alert.metadata	No	metadata: key value;	Alert metadata. The specification of the fields is open.
alert.rev	Yes	rev	Alert's revision number.
alert.severity	Yes	-	Severity level of the alert.
alert.signature	Yes	msg	Description of the alert.
alert.signature_id	Yes	sid	Alert identifier. It must be a unique one.
app_proto	No	-	Application protocol of the flow from which the file originates.
dest_ip	Yes	-	Destination IP address.
dest_port	No	-	Destination port. Only present when the value of proto is udp or tcp.
event_type	Yes	-	Type of event. Alert by default.
flow.age	No	-	Flow duration.
flow.bytes_toclient	Yes	-	Size of the flow to the client.
flow.bytes_toserver	Yes	-	Size of the flow to the server.
flow.end	No	-	Date and time of the last package seen by suricata.
flow.pkts_toclient	Yes	-	Number of packets to the client.
flow.pkts_toserver	Yes	-	Number of packets to the server.
flow.reason	No	-	Mechanism causing the flow to stop processing between ("timeout", "forced", and "shutdown")
flow.start	Yes	-	Date and time of the first package seen by suricata.
flow.state	No	-	The status of the flow between ("new", "established", "closed", "bypassed")
file_id	Yes	-	Flow identifier.
gcap	Yes	-	Name of the gcap assigned to the alert.
gcenter	Yes	-	Name of the GCenter assigned to the alert.
host	Yes	-	Name of the gcap assigned to the alert.
in_iface	No		Capture interface on the gcap.
packet	No	-	Package in base64 format. Only present if the packet option in the gcap "variable bases" menu is enabled.
payload	No	-	Payload in base64 format. Only present if the payload option in the gcap "variable bases" menu is enabled.
packet_info.linktype	Yes	-	-
payload_printable	No	-	Package payload in a readable format. Only present if the payload-printable option in the gcap "variable bases" menu is enabled.
proto	Yes	-	Layer 4 protocol used.
severity	Yes	-	Severity level of the alert.
src_ip	Yes	-	Destination IP address.
src_port	No	-	Destination port. Only present when the value of proto is udp or tcp.
stream	Yes	-	-
timestamp_analyzed	Yes	-	Date and time of the alert analysis by logstash.
timestamp_detected	Yes	-	Date and time of suricata generated the alert.
type	Yes		Type of event. Suricata by default.
uuid	Yes	-	Unique alert identifier.
vlan	No	-	Vlan identifier of the flow.

List of metadata used in the source alerts (alert.metadata object in ES):

alert.metadata.affected_product
alert.metadata.attack_target
alert.metadata.created_at
alert.metadata.deployment
alert.metadata.former_category
alert.metadata.impact_flag
alert.metadata.malware_family
alert.metadata.performance_impact
alert.metadata.ruleset
alert.metadata.service
alert.metadata.signature_severity
alert.metadata.tag
alert.metadata.updated_at

Here is an example of an alert using the metadata affected_product, attack_target, created_at, deployment, signature_severity, tag and updated_at:

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 (
msg:"ET EXPLOIT MS-SQL SQL Injection closing string plus line comment";
flow: to_server,established;
content:"'|00|";
content:"-|00|-|00|";  
reference:url,doc.emergingthreats.net/bin/view/Main/2000488;
classtype:attempted-user;
sid:2000488;
rev:7;
metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2016_07_01;
)

5.2. Document type "fileinfo"

List of fields present in all alerts with event_type == fileinfo:

@timestamp
@version
app_proto
dest_ip
dest_port
event_type
fileinfo.filename
fileinfo.gaps
fileinfo.size
fileinfo.state
fileinfo.stored
fileinfo.tx_id
flow_id
gcap
GCenter
host
proto
src_ip
src_port
timestamp_analyzed
timestamp_detected
type
uuid

Summary table of fields that do not depend on the protocols:

Fields	Required	Description
app_proto	Yes	Application protocol of the flow from which the file originates.
dest_ip	Yes	Destination's IP address.
dest_port	Yes	Destination port. Only present when the value of proto is udp or tcp.
event_type	Yes	Type of event.
fileinfo.file_id	No	File identifier.
fileinfo.filename	Yes	File name.
fileinfo.gaps	Yes	-
fileinfo.magic	No	File type identifier.
fileinfo.md5	No	Hash MD5 of the file.
fileinfo.sha1	No	Hash SHA1 of the file.
fileinfo.sha256	No	Hash SHA256 of the file.
fileinfo.size	Yes	File size.
fileinfo.state	Yes	Completeness of the analysed file (CLOSED) otherwise TRUNCATED. The file-store.stream-depth variable of suricata defines the size of the reconstructed files. The file is TRUNCATED if its size is > File-store stream-depth (10 MB) by default.
fileinfo.stored	Yes	True if the file is rebuilt and False otherwise.
fileinfo.tx_id	Yes	-
file_id	Yes	Flow identifier.
gcap	Yes	Name of the gcap assigned to the alert.
gcenter	Yes	Name of the GCenter assigned to the alert.
host	Yes	Name of the gcap assigned to the alert.
in_iface	No	Capture interface on the gcap.
proto	Yes	Layer 4 protocol used.
src_ip	Yes	Destination IP address.
src_port	No	Destination port. Only present when the value of proto is udp or tcp.
timestamp_analyzed	Yes	Date and time of the alert analysis by logstash.
timestamp_detected	Yes	Date and time of suricata generated the alert.
type	Yes	Type of event. Suricata by default.
uuid	Yes	Unique alert identifier.
vlan	No	Vlan identifier of the flow.

5.3. Metadata document

List of fields present in all alerts with event_type != ["alert", "fileinfo", "stats"]:

@timestamp
@version
dest_ip
event_type
flow_id
gcap
GCenter
host
proto
src_ip
timestamp_analyzed
timestamp_detected
type
uuid

List of protocols compatible with logging (champ event_type):

dhcp:
- dhcp.assigned_ip
- dhcp.client_ip
- dhcp.client_mac
- dhcp.dhcp_type
- dhcp.dns_servers
- dhcp.hostname
- dhcp.id
- dhcp.lease_time
- dhcp.next_server_ip
- dhcp.params
- dhcp.rebinding_time
- dhcp.relay_ip
- dhcp.renewal_time
- dhcp.requested_ip
- dhcp.routers
- dhcp.subnet_mask
- dhcp.type
dnp3
dns:
- body.proba_dga
- body.severity
- dga_probability
- dns.aa
- dns.answers.rdata
- dns.answers.rrname
- dns.answers.rrtype
- dns.answers.ttl
- dns.authorities.rrname
- dns.authorities.rrtype
- dns.authorities.ttl
- dns.flags
- dns.grouped.A
- dns.grouped.AAAA
- dns.grouped.CNAME
- dns.id
- dns.qr
- dns.ra
- dns.rcode
- dns.rd
- dns.rrname
- dns.rrtype
- dns.tx_id
- dns.type
- dns.version
- headers.content-length
- headers.content-type
- tags
ftp
http:
- http.accept
- http.accept-charset
- http.accept-datetime
- http.accept_encoding
- http.accept_language
- http.accept-range
- http.age
- http.allow
- http.authorization
- http.cache_control
- http.connection
- http.content_encoding
- http.content-language
- http.content-length
- http.content-location
- http.content-md5
- http.content-range
- http.content_type
- http.content-type
- http.cookie
- http.date
- http.dnt
- http.etags
- http.from
- http.hostname
- http.http_content_type
- http.http_method
- http.http_port
- http.http_refer
- http.http_user_agent
- http.last-modified
- http.length
- http.link
- http.location
- http.max-forwards
- http.origin
- http.pragma
- http.proxy-authenticate
- http.proxy-authorization
- http.range
- http.redirect
- http.referrer
- http.refresh
- http.retry-after
- http.server
- http.set-cookie
- http.status
- http.te
- http.trailer
- http.transfer-encoding
- http.upgrade
- http.url
- http.vary
- http.via
- http.warning
- http.www-authenticate
- http.x-authenticated-user
- http.x-flash-version
- http.x-forwarded-proto
- http.x-requested-with
ikev2:
- ikev2.alg_auth
- ikev2.alg_dh
- ikev2.alg_enc
- ikev2.alg_esn
- ikev2.alg_prf
- ikev2.errors
- ikev2.exchange_type
- ikev2.init_spi
- ikev2.message_id
- ikev2.notify
- ikev2.payload
- ikev2.resp_spi
- ikev2.role
- ikev2.version_major
- ikev2.version_minor
krb5:
- krb5.cname
- krb5.encryption
- krb5.error_code
- krb5.failed_request
- krb5.msg_type
- krb5.realm
- krb5.sname
- krb5.weak_encryption
netflow:
- icmp_code
- icmp_type
- metadata.flowbits
- netflow.age
- netflow.bytes
- netflow.end
- netflow.max_ttl
- netflow.min_ttl
- netflow.pkts
- netflow.start
- parent_id
- tcp.ack
- tcp.cwr
- tcp.ecn
- tcp.fin
- tcp.psh
- tcp.rst
- tcp.syn
- tcp.tcp_flags
nfs:
- nfs.file_tx
- nfs.filename
- nfs.hhash
- nfs.id
- nfs.procedure
- nfs.rename.from
- nfs.rename.to
- nfs.status
- nfs.type
- nfs.version
- rpc.auth_type
- rpc.creds.gid
- rpc.creds.machine_name
- rpc.creds.uid
- rpc.status
- rpc.xid
smb:
- smb.access
- smb.accessed
- smb.changed
- smb.client_dialects
- smb.client_guid
- smb.command
- smb.created
- smb.dcerpc.call_id
- smb.dcerpc.interfaces.ack_reason
- smb.dcerpc.interfaces.ack_result
- smb.dcerpc.interfaces.uuid
- smb.dcerpc.interfaces.version
- smb.dcerpc.opnum
- smb.dcerpc.req.frag_cnt
- smb.dcerpc.req.stub_data_size
- smb.dcerpc.request
- smb.dcerpc.res.frag_cnt
- smb.dcerpc.res.stub_data_size
- smb.dcerpc.response
- smb.dialect
- smb.directory
- smb.disposition
- smb.filename
- smb.fuid
- smb.function
- smb.id
- smb.modified
- smb.named_pipe
- smb.ntlmssp.domain
- smb.ntlmssp.host
- smb.ntlmssp.user
- smb.request.native_lm
- smb.request.native_os
- smb.response.native_lm
- smb.response.native_os
- smb.server_guid
- smb.service.request
- smb.service.response
- smb.session_id
- smb.share
- smb.share_type
- smb.size
- smb.status
- smb.status_code
- smb.tree_id
smtp:
- email.attachment
- email.body_md5
- email.from
- email.status
- email.subject
- email.subject_md5
- email.to
- smtp.helo
- smtp.mail_from
- smtp.rcpt_to
ssh:
- ssh.client.proto_version
- ssh.client.software_version
- ssh.server.proto_version
- ssh.server.software_version
tftp:
- tftp.file
- tftp.mode
- tftp.packet
tls:
- tls.chain
- tls.fingerprint
- tls.issuerdn
- tls.notafter
- tls.notbefore
- tls.sni
- tls.subject
- tls.version

Summary table of fields that do not depend on the protocols:

Fields	Required	Description
app_proto	No	Application protocol of the flow from which the file originates.
dest_ip	Yes	Destination's IP address.
dest_port	No	Destination port. Only present when the value of proto is udp or tcp.
event_type	Yes	Type of event. Alert by default.
file_id	Yes	Flow identifier.
gcap	Yes	Name of the gcap assigned to the alert.
gcenter	Yes	Name of the GCenter assigned to the alert.
host	Yes	Name of the gcap assigned to the alert.
in_iface	No	Capture interface on the gcap.
proto	Yes	Layer 4 protocol used.
src_ip	Yes	Destination IP address.
src_port	No	Destination port. Only present when the value of proto is udp or tcp.
timestamp_analyzed	Yes	Date and time of the alert analysis by logstash.
timestamp_detected	Yes	Date and time of suricata generated the alert.
type	Yes	Type of event. Suricata by default.
uuid	Yes	Unique alert identifier.
vlan	No	Vlan identifier of the flow.