firewall

service firewall <id>

Devices Licenses

Values:

id –
Firewall IDS and IPS client configuration

Only these characters are allowed to be used for setting the client name: alphanumeric characters: a-z A-Z 0-9 special characters: - ( ) , . : _ Notice that also maximum length is limited up to 128 characters. You can define either one client or multiple clients each one having its own configuration and using the defined NFQ queues. Once completed, each client will have its own daemon and you can monitor its status in the operational CLI.

Instances:

Multiple

Required:

service firewall <id> mode

Required:

service firewall <id> ruleset

service firewall <id> action-order <id>

Devices Licenses

Values:

id –
Order in which actions have to be processed

Comma-separated list containing the following actions in order of preference

service firewall <id> algorithm <id>

Devices Licenses

Multi pattern algorithm you want to run for scan/search the engine

The mpm you choose also decides the distribution of mpm contexts for signature groups. Selecting “ac” requires a single mpm context while the rest of the mpms can run in “full” mode.

Values:

ac – Aho-Corasick, default implementation
ac-bs – Aho-Corasick, reduced memory implementation
ac-ks – Aho-Corasick, “Ken Steele” variant
auto – Determines the best available algorithm to use
hs – Hyperscan, only available at x86_64 processors with SSSE3 support
vs – Vectorscan, only available at aarch64 processors with SIMD support

service firewall <id> bypass

Devices Licenses

Skip a flow/session from being analyzed when meets certain conditions

bypass can lead to missing important traffic. Use with care

service firewall <id> bypass action

Devices Licenses

Actions to apply to the packet and/or flow when a verdict takes place

There are three possible verdicts for a packet/flow that is analyzed by the firewall: - Accept - Drop - Block Such verdict initially accepts only the packet itself but it is also possible to change the entire flow control associated with such packet. In example, if a packet can be bypassed the flow can also be bypassed. Either way, if a packet must be dropped the entire flow shall be dropped also. The block verdict is special: the packet is accepted but the connection is marked with a configurable connmark. This allows external firewall rules to handle the marked connection (e.g., redirect to a block page via traffic-proxy). This helps preventing packets reaching the firewall and taking either the “fast-path” (bypass), being dropped as soon as possible, or being marked for external handling.

service firewall <id> bypass action block

Devices Licenses

Actions to apply to a flow/session when it is blocked

The block action is used with the ‘block’ keyword in firewall rules. When a rule with the block keyword matches, the packet is accepted but the connection is marked with a configurable connmark. This allows external firewall rules (nftables/iptables) to handle the marked connection, typically to redirect traffic to a block page or proxy.

service firewall <id> bypass action block set: Devices Licenses
Modify the packet and/or flow when a block verdict takes place

service firewall <id> bypass action block set connmark

Devices Licenses

Set connmark when blocking a traffic flow

Use block connmark for implementing connection marking on blocked flows. The firewall will set the given mark on a flow that matches a rule with the ‘block’ keyword. External firewall rules can then match on this connmark to redirect traffic to a block page or perform other actions.

Instances:: Unique

service firewall <id> bypass action block set connmark extra-mark <int>

Devices Licenses

Set an extra mark (emark1) when blocking a traffic flow

Values:

1 – Extra mark 1 (emark2 is reserved for tproxy)

Instances:

Multiple

service firewall <id> bypass action block set connmark extra-mark <int> value <u32>

Devices Licenses

Values:

u32 – Value to set on extra connmark

service firewall <id> bypass action block set connmark mark <u32>

Devices Licenses

Values:

u32 – Set a connmark

service firewall <id> bypass action block set connmark vrf-mark <id>

Devices Licenses

Set connmark using a VRF

Reference:: system vrf <id>

service firewall <id> bypass action drop: Devices Licenses
Actions to apply to a flow/session when it is dropped

service firewall <id> bypass action drop set: Devices Licenses
Modify the packet and/or flow when a verdict takes place

service firewall <id> bypass action drop set connmark

Devices Licenses

Set connmark when filtering a traffic flow to perform capture bypass

Use bypass connmark for implementing capture bypass. The firewall will set the given mark on a filtered flow that needs to be bypassed. The ruleset has to directly drop all packets of a flow once it has been marked.

Instances:: Unique

service firewall <id> bypass action drop set connmark extra-mark <u32>

Devices Licenses

Set an extra connmark

Values:

u32 – Extra mark index (1-2)

Instances:

Multiple

service firewall <id> bypass action drop set connmark extra-mark <u32> value <u32>

Devices Licenses

Values:

u32 – Extra mark value

service firewall <id> bypass action drop set connmark mark <u32>

Devices Licenses

Values:

u32 – Set a connmark

service firewall <id> bypass action drop set connmark vrf-mark <id>

Devices Licenses

Set connmark using a VRF

Reference:: system vrf <id>

service firewall <id> detect-thread-ratio <float>

Devices Licenses

Detect threads ratio available per CPU core

By default, the firewall creates one “detect” thread per available CPU/CPU core. This setting allows controlling this behaviour. A ratio setting of “2” will create 2 detect threads for each CPU/CPU core. So for a dual core CPU this will result in 4 detect threads. If values below 1 are used, less threads are created. Following the example above, a ratio of 0.5 will result in 1 detect thread being created. Regardless of this setting, a minimum 1 detect thread will always be created

Values:

float – Detection threads ratio - this value is multiplied by the amount of CPU/CPU cores. (0-65535)

service firewall <id> flow

Devices Licenses

Flow configuration for firewall stream engine

Flows are very important - they play a big part in the way the firewall organizes data internally. A flow is a bit similar to a conntrack entry, except that a flow is more general: all packets having the same tuple (source, destination, source port and destination port) belong to the same flow.

service firewall <id> flow hash-size <u32>

Devices Licenses

Values:

u32 – Size of the hash-table used for organizing flows

service firewall <id> flow max-memory <id>

Devices Licenses

Values:

id –
Max memory usage (in bytes) for storing flow information

Keeping track of all flows that are taking place uses memory. In particular, the more flows the more memory it will cost. At the point in which this value is reached, despite the value of “prealloc”, the flow engine goes into “emergency-mode” and sets shorter timeouts so flows expire earlier (and there is more space for new flows). Defaults to 128MB.

service firewall <id> flow memcap-policy <id>

Devices Licenses

Values:

id –
Memcap policy

Memcap policy defines how Suricata should handle packet processing when memory limits are reached. The available options are: - drop-packet: When memory limits are exceeded, Suricata will drop incoming packets to prevent further memory usage. - pass-packet: Suricata will allow the packet to pass through. - reject: Suricata will reject the packet and send an error response. - ignore (default): This is the default behavior. Suricata will simply ignore the packet and will continue to process other packets normally. Choose the appropriate memcap policy based on your system’s memory and traffic needs.

service firewall <id> flow prealloc <u32>

Devices Licenses

Values:

u32 –
Number of pre-allocated flows created when starting the firewall

For packets not yet belonging to a flow, the firewall creates one. This operation is a really expensive action and comes with a risk: attackers can compromise the engine system at this part by flooding it if sending lots of packets with different tuples. In such situation, the engine has to create plenty of flows and can easily become overloaded. This setting though instructs the firewall to keep a number of flows ready in memory so it is less vulnerable to this attacks. Defaults to 10000 pre-allocated flows.

service firewall <id> hashset: Devices Licenses
Set of hashes to be used by the firewall when registering traffic

service firewall <id> hashset file <file>

Devices Licenses

Values:

file –
File from which different hashes will be loaded

All hashes included in the hashset must be calculated with the same hash function (md5, sha1 or sha256)

Instances:

Multiple

service firewall <id> logging

Devices Licenses

Firewall engine logging options

The engine logging system logs information about the application such as errors and other diagnostic information during startup, runtime and shutdown of the firewall engine. Notice that this does not include firewall generated alerts and events.

service firewall <id> logging filter <txt>

Devices Licenses

RegEx expression for filtering logging output

With the output filter you can set which part of the event-logs should be displayed. This way, a line will be shown only if the RegEx matches

Values:

txt – POSIX extended regular expression

service firewall <id> logging level <id>

Devices Licenses

Values:

id –
Firewall engine log level

Determines the severity/importance level of information that will be displayed. Messages of lower levels than the set here will not be shown. Notice that the debug level logging may not be available

service firewall <id> logging outputs

Devices Licenses

Output types used when logging

There are several types of output in the firewall: engine statistics, packet counters, etc. Be careful on which log outputs you enable as enabling all of the logs will result in a much lower performance and the use of more disc space

service firewall <id> logging outputs eve

Devices Licenses

JSON output for alerts and events

The EVE (Extensible Event Format) is an standard JSON output widely used which allows easy integration with 3rd party tools.

service firewall <id> logging outputs eve filetype <id>

Devices Licenses

EVE output filetype destination

Values:

regular – Output to a JSON file
redis – Output to a Redis server
syslog – Output to the system log

service firewall <id> logging outputs eve redis

Devices Licenses

Redis settings for EVE logging

Required:: service firewall <id> logging outputs eve redis key <id>

service firewall <id> logging outputs eve redis async <bool>

Devices Licenses

Values:

bool – Read Redis replies asynchronously

service firewall <id> logging outputs eve redis key <id>

Devices Licenses

Values:

id – Key or channel to use

service firewall <id> logging outputs eve redis mode <id>

Devices Licenses

Mode in which events are sent to Redis

Values:

list – Alias for lpush
channel – Alias for publish
lpush – Insert at the beginning of the queue (head)
rpush – Insert at the end of the queue (tail)
publish – Publish events in specified channel

service firewall <id> logging outputs eve redis port <u32>

Devices Licenses

Port in which Redis server is listening to

Values:

u32 – Numeric IP port (1-32767)
u32 – Numeric IP port (60000-65535)

service firewall <id> logging outputs eve redis server <ipv4|ipv6|fqdn>

Devices Licenses

Remote address in which Redis server is available

Values:

ipv4 – IPv4 address of the Redis server
ipv6 – IPv6 address of the Redis server
fqdn – Hostname of the Redis server

service firewall <id> logging outputs eve syslog

Devices Licenses

Syslog settings for EVE logging

Required:: service firewall <id> logging outputs eve syslog identity <id>

service firewall <id> logging outputs eve syslog identity <id>

Devices Licenses

Identifier when generating syslog messages

Defining an identifier allows later filtering of syslog messages so they can be, for example, send to a remote server based on this identity.

Values:

id – Identifier when generating syslog messages

service firewall <id> logging outputs eve syslog level <id>

Devices Licenses

Severity level used when generating syslog messages

The severity level allows you to define an output level for the generated events. Later on, adjusting “system console log-level” lets you delimit which messages are shown in the system journal.

Values:

emergency – A panic condition, meaning that the system is unusable
alert – A risky situation that implies that an action must be taken immediately
critical – A critical condition that has happened because of this event
error – Error conditions
warning – Warning conditions
notice – Normal but significant conditions that may require special handling
info – Informational messages that indicate that everything is worked as expected
debug – Debug messages normally used for debugging an application

service firewall <id> logging outputs eve types: Devices Licenses
Event types settings for EVE logging

service firewall <id> logging outputs eve types drop: Devices Licenses
Drop info module settings for EVE logging

service firewall <id> logging outputs eve types drop flows <id>

Devices Licenses

Logging of packet drops.

Values:

all – Log every dropped packet
start – Log only a single drop per flow direction.

service firewall <id> logging outputs eve types files: Devices Licenses
File info module settings for EVE logging

service firewall <id> logging outputs eve types files force-hash <id>

Devices Licenses

Logging of checksums from detected files

Values:

md5 – Log md5 hash from detected files
sha1 – Log sha1 hash from detected files
sha256 – Log sha256 hash from detected files

Instances:

Multiple

service firewall <id> logging outputs fast: Devices Licenses
Alerts consisting only on a single line

service firewall <id> logging outputs http: Devices Licenses
Keep tracking of all HTTP requests

service firewall <id> logging outputs pcap: Devices Licenses
Save all packages registered by the firewall

service firewall <id> logging outputs syslog

Devices Licenses

Fast-like logging messages written to syslog

Required:: service firewall <id> logging outputs syslog identity <id>

service firewall <id> logging outputs syslog identity <id>

Devices Licenses

Identifier when generating syslog messages

Defining an identifier allows later filtering of syslog messages so they can be, for example, send to a remote server based on this identity.

Values:

id – Identifier when generating syslog messages

service firewall <id> logging outputs syslog level <id>

Devices Licenses

Severity level used when generating syslog messages

The severity level allows you to define an output level for the generated events. Later on, adjusting “system console log-level” lets you delimit which messages are shown in the system journal.

Values:

emergency – A panic condition, meaning that the system is unusable
alert – A risky situation that implies that an action must be taken immediately
critical – A critical condition that has happened because of this event
error – Error conditions
warning – Warning conditions
notice – Normal but significant conditions that may require special handling
info – Informational messages that indicate that everything is worked as expected
debug – Debug messages normally used for debugging an application

service firewall <id> logging outputs tls: Devices Licenses
Line-based log of TLS handshake parameters

service firewall <id> logging outputs verbose: Devices Licenses
Supplementary information about an alert

service firewall <id> logging rotation: Devices Licenses
Firewall logging rotation options

service firewall <id> logging rotation amount <u32>

Devices Licenses

Values:

u32 –
Amount of old log files to keep

Log files are rotated ‘N’ times before being removed. If count is 0 then old versions are removed rather than rotated.

service firewall <id> logging rotation compress: Devices Licenses
Enable compression of old log files using gzip

service firewall <id> logging rotation periodic <id>

Devices Licenses

Periodic rotation for firewall logging files

Values:

hourly – Hourly rotation of log files
daily – Daily rotation of log files
weekly – Weekly rotation of log files
monthly – Monthly rotation of log files
yearly – Yearly rotation of log files

service firewall <id> logging rotation size <id>

Devices Licenses

Values:

id –
Size based rotation of log files

Log files are rotated only if they grow bigger than “size” bytes. If size is followed by a ‘k’ then is assumed to be kilobytes. If ‘M’ is used, size is in megabytes and if ‘G’ is used, the size is in gigabytes. So “size 100”, “size 100k”, “size 100M” and “size 100G” are all valid. In addition, this option can be mixed with the periodic one, meaning that a log file usually is rotated when the specified interval has passed unless the file grows bigger than the given size.

service firewall <id> max-pending-packets <u32>

Devices Licenses

Values:

u32 –
Number of packets preallocated per thread

With this setting you can set the number of packets you allow the firewall to process simultaneously. This can range from one packet to tens of thousands of thousands of packets. It is a trade of higer performance and higher memory usage or lower performance and lower memory usage (in terms of RAM). Choosing a low number of packets being processed while having many CPUs can result in not making use of the whole router capacity

service firewall <id> mode

Devices Licenses

Firewall running mode

Instances:: Unique

service firewall <id> mode inline

Devices Licenses

Run the firewall in inline mode

From the two modes available, this one is the widely used one. Inline mode puts the firewall in between communications and checks traffic based on given rules, dropping it if necessary or allowing the packets

service firewall <id> mode inline queue <txt>

Devices Licenses

Queue(s) used by the firewall when registering traffic

Using NFQUEUE in nftables rules will send packets to the firewall. You can define at traffic policies how much queues will be created and how do they behave. Having multiple queues is known as a load-balanced setup from which the firewall can obtain packets.

Reference:: traffic queue <txt>

service firewall <id> mode monitor

Devices Licenses

Run the firewall in monitor mode

Monitor mode runs the firewall as if it was a sniffer: looking at every packet received on the given interface(s) and generating alerts based on the given rulesets. Nevertheless, this mode does nothing with packets and they are always accepted. Notice that monitor mode may use more system resources.

service firewall <id> mode monitor interfaces <ifc>

Devices Licenses

Values:

ifc –
Interfaces to monitor

You can configure the firewall to listen on mutiple interfaces, depending on your needs. Take into account that more interfaces is more traffic so more system resources are needed.

Instances:

List of values

service firewall <id> ruleset: Devices Licenses
Set of rules to be used by the firewall when registering traffic

service firewall <id> ruleset compressed <file>

Devices Licenses

Values:

file – Compressed file containing

Instances:

Multiple

service firewall <id> ruleset compressed <file> digest <id>

Devices Licenses

Values:

id – If the ruleset is encrypted, digest used during key derivation

service firewall <id> ruleset compressed <file> encrypted-password <password>

Devices Licenses

Values:

password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset compressed <file> file <txt>

Devices Licenses

Values:

txt – File(s) inside the compressed ruleset to use - if not defined, every present file will be used

Instances:

Multiple

service firewall <id> ruleset compressed <file> iterations <u32>

Devices Licenses

Values:

u32 – If the ruleset is encrypted and the key derived with PBKDF2, the iterations used during derivation (usually, 10000)

service firewall <id> ruleset compressed <file> key-length <u32>

Devices Licenses

If the ruleset is encrypted, the key length used during key derivation

Values:

u32 – “File was encrypted using AES-128” (128)
u32 – “File was encrypted using AES-192” (192)
u32 – “File was encrypted using AES-256” (256)

service firewall <id> ruleset compressed <file> password <txt>

Devices Licenses

Values:

txt –
If the ruleset is encrypted, the password used for decrypting it

Due to intellectual property, one can opt-in for encrypting their ruleset. Currently, OSDx supports having the ruleset encrypted with AES-CBC 128/192/256 with multiple digest algorithms.

service firewall <id> ruleset file <file>

Devices Licenses

Values:

file – File from which different rules will be loaded

Instances:

Multiple

service firewall <id> ruleset file <file> digest <id>

Devices Licenses

Values:

id – If the file is encrypted, digest used during key derivation

service firewall <id> ruleset file <file> encrypted-password <password>

Devices Licenses

Values:

password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset file <file> iterations <u32>

Devices Licenses

Values:

u32 – If the file is encrypted and the key derived with PBKDF2, the iterations used during derivation (usually, 10000)

service firewall <id> ruleset file <file> key-length <u32>

Devices Licenses

If the file is encrypted, the key length used during key derivation

Values:

u32 – “File was encrypted using AES-128” (128)
u32 – “File was encrypted using AES-192” (192)
u32 – “File was encrypted using AES-256” (256)

service firewall <id> ruleset file <file> password <txt>

Devices Licenses

Values:

txt –
If the file is encrypted, the password used for decrypting it

Due to intellectual property, one can opt-in for encrypting their files. Currently, OSDx supports having the files encrypted with AES-CBC 128/192/256 with multiple digest algorithms.

service firewall <id> ruleset patch <file>

Devices Licenses

Values:

file –
Patch file applied to an existing ruleset

Patch file are files that are generated with the “diff” tool and contains the minimum amount of bytes for upgrading from one version of a file to the next one. In this situation, patches are using for changing some rules in a ruleset without needing to download the entire ruleset again. Notice that the filenames (ruleset and patch) must be equals: - Ruleset: ddos-drop.rules - Patch: ddos-drop.patch

Instances:

Multiple

service firewall <id> ruleset patch <file> digest <id>

Devices Licenses

Values:

id – If the patch is encrypted, digest used during key derivation

service firewall <id> ruleset patch <file> encrypted-password <password>

Devices Licenses

Values:

password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset patch <file> file <txt>

Devices Licenses

Values:

txt – File(s) inside the compressed patchset to use - if not defined, every present file will be used

Instances:

Multiple

service firewall <id> ruleset patch <file> iterations <u32>

Devices Licenses

Values:

u32 – If the patch is encrypted and the key derived with PBKDF2, the iterations used during derivation (usually, 10000)

service firewall <id> ruleset patch <file> key-length <u32>

Devices Licenses

If the patch is encrypted, the key length used during key derivation

Values:

u32 – “File was encrypted using AES-128” (128)
u32 – “File was encrypted using AES-192” (192)
u32 – “File was encrypted using AES-256” (256)

service firewall <id> ruleset patch <file> password <txt>

Devices Licenses

Values:

txt –
If the patch is encrypted, the password used for decrypting it

Due to intellectual property, one can opt-in for encrypting their patchset. Currently, OSDx supports having the patchset encrypted with AES-CBC 128/192/256 with multiple digest algorithms.

service firewall <id> runmode <id>

Devices Licenses

Values:

id –
Runmode the engine should use.

Firewall consists on several building blocks running all together. The way such building blocks are arranged together is called “runmode”, and there are several predefined: single, workers and autofp. - workers: generally, gives the best performance. Packets are properly balanced over firewall processing units. - autofp: usually used when processing PCAP files or certain IPS setups, like NFQ. There are more capture units and the packet is served to the processing untis. Choosing each runmode will directly affect the performance of the firewall, so it is recommended to tweak this setting under your needs.

service firewall <id> stats: Devices Licenses
Engine statistics such as packet counters, memory use counters and more

service firewall <id> stats interval <u32>

Devices Licenses

Values:

u32 –
Interval in seconds in which statistics are dumped

Setting this value below 3 or 4 seconds is not useful due to how the processing units are synchronized internally

service firewall <id> stream

Devices Licenses

Stream engine configuration for TCP connections

The stream engine keeps track of TCP connections. The engine consists on two parts: the stream tracking and the reassembly engine. The stream tracking engine monitors the state of a connection. The reassembly engine reconstructs the flow as it used to be, so it will be recognized by the firewall.

service firewall <id> stream async-oneside

Devices Licenses

Async stream handling

Some networks make it more complicated to see all packets of a connection: network-traffic follows a different route than the other part, which means that traffic goes asynchronous. Enable this option to make sure that the firewall will check the one part it does see, instead of “getting confused”

service firewall <id> stream bypass

Devices Licenses

Bypasses a flow/session when either side reaches its depth

bypass can lead to missing important traffic. Use with care

service firewall <id> stream bypass action

Devices Licenses

Actions to apply to the packet and/or flow when a verdict takes place

There are two possible verdicts for a packet/flow that is analyzed by the firewall: - Accept - Drop Such verdict initially accepts only the packet itself but it is also possible to change the entire flow control associated with such packet. In example, if a packet can be bypassed the flow can also be bypassed. Either way, if a packet must be dropped the entire flow shall be dropped also. This helps preventing packets reaching the firewall and taking either the “fast-path” (bypass) or being dropped as soon as possible (when they are received by the kernel).

service firewall <id> stream bypass action accept

Devices Licenses

Actions to apply to the packet and/or flow when they are accepted

If a packet/flow is accepted and can be bypassed (either because of rules or because the maximum depth was reached), the actions that are set will be executed.

service firewall <id> stream bypass action accept set: Devices Licenses
Attributes to set to a packet/flow whenever it is accepted

service firewall <id> stream bypass action accept set conntrack

Devices Licenses

Attributes to set to the flow associated with the analyzed packet

Set some specific attributes to the conntrack associated with the analyzed packet when such packet is accepted.

service firewall <id> stream bypass action accept set conntrack offload-flag

Devices Licenses

Set the offload flag to the flow associated with the accepted packet

Enabling this option will change the status of the conntrack flow associated with the accepted packet, marking it as possibly bypassed. You can run “show system conntrack” and should see “(Sc: bypass)” within the marked flow.

service firewall <id> stream bypass action drop

Devices Licenses

Actions to apply to the packet and/or flow when they are dropped

If a packet/flow is dropped, the actions that are set will be executed.

service firewall <id> stream bypass action drop set: Devices Licenses
Attributes to set to a packet/flow whenever it is dropped

service firewall <id> stream bypass action drop set xdp-early-drop <ifc>

Devices Licenses

Values:

ifc –
Set an XDP filter per interface that will drop malicious flows

Configuring a list of interfaces will install an XDP filter per interface, which can be used by the firewall for notifying about a flow that can be dropped at the earliest stage possible. This option is very useful for preventing packets from reaching the firewall but also the kernel, making it the greatest option when trying, for example, to protect against a DDoS attack.

Instances:

List of values

service firewall <id> stream bypass depth <id>

Devices Licenses

Depth of the reassembly

Maximum depth of the reassembly in which packets are bypassed when reached. This field accepts a value in bytes with an optional suffix indicating the magnitude (K/M). The value must be within 5KB and 50MB

Values:

u32 – Size in bytes with optional K/M suffix

service firewall <id> stream bypass extra-mark <int>

Devices Licenses

Set extra mark to perform capture bypass

Use some extra mark for implementing capture bypass. The behavior is the same as when setting both “mark” and “mask” and takes place in whether packet mark or conntrack mark depending on the “set-extra-connmark” option. By default, the firewall will set the given mark on a packet of a flow that needs to be bypassed.

Values:

int – Extra mark index (1-2)

Instances:

Multiple

Required:

service firewall <id> stream bypass extra-mark <int> value <u32>

Required:

service firewall <id> stream bypass extra-mark <int> mask <u32>

service firewall <id> stream bypass extra-mark <int> mask <u32>

Devices Licenses

Values:

u32 – Extra mark mask

service firewall <id> stream bypass extra-mark <int> set-extra-connmark: Devices Licenses
Set conntrack mark instead of packet mark to perform capture bypass

service firewall <id> stream bypass extra-mark <int> value <u32>

Devices Licenses

Values:

u32 – Extra mark value

service firewall <id> stream bypass mark <u32>

Devices Licenses

Values:

u32 –
Set packet mark to perform capture bypass

Use bypass mark for implementing capture bypass. The firewall will set the given mark on a packet of a flow that needs to be bypassed. The ruleset has to directly accept all packets of a flow once it has been marked.

service firewall <id> stream bypass mask <u32>

Devices Licenses

Values:

u32 –
Set packet mask to perform capture bypass

Use bypass mask for implementing NFQ bypass. Note than the mask is used by the firewall to detect whether the packet/flow must be bypassed by NFQ by doing the ‘AND’ operation with such values (bypass_mask & bypass_mark). The firewall will set then the given mask on a packet of a flow that needs to be bypassed. The ruleset has to directly accept all packets of a flow once it has been marked.

service firewall <id> stream bypass set-connmark

Devices Licenses

Set conntrack mark instead of packet mark to perform capture bypass

The final behavior is the same as when only setting both “mark” and “mask” with the difference that the resulting mark will be set into the conntrack mark instead.

service firewall <id> stream drop-invalid: Devices Licenses
Drop packets that are seen invalid by the stream engine

service firewall <id> stream inline <id>

Devices Licenses

Set stream to inline mode so the firewall switches to blocking mode

Values:

yes – Stream is always in inline mode - firewall always blocking
no – Stream is never in inline mode
auto – Stream is only in inline mode if IPS is enabled

service firewall <id> stream max-memory <id>

Devices Licenses

Values:

id –
Max memory usage (in bytes) for tracking a TCP session

Firewall stream tracking engine keeps information about the flow being tracked in

service firewall <id> stream midstream

Devices Licenses

Pick sessions that have already started

A TCP session starts with the three-way-handshake. After that, data can be sent and received. As a session can last a long time, it may happend that the firewall is started after a few TCP sessions have started, missing the original setup of all those sessions (which usually includes a lot of information). If you want to allow the firewall to join a session after it has started, mark this option

service firewall <id> stream no-validate-checksum

Devices Licenses

Process all packets, even if they have an invalid valid checksum

All TCP packets have a so-called checksum. This is an internal code which makes possible to see if a packet has arrived in a good state. The stream-engine will not process packets with a wrong checksum unless this option is enabled

service firewall <id> stream reassembly-max-memory <id>

Devices Licenses

Values:

id –
Max memory reserved (in bytes) for stream data reconstruction

Stream reassembly is an expensive operation and uses lots of resources. For avoiding resource starvation, maximum reserved memory can be limited so reduce memory usage. Defaults to 256MB.

service firewall <id> tls-detection: Devices Licenses
TLS detection enabling and configuration

service firewall <id> tls-detection detection-ports <u32>

Devices Licenses

Port on which the TLS parser should listen, defaults to 443

Values:

u32 – Port number (1-65535)

Instances:

List of values

service firewall <id> tls-detection ja3-fingerprints: Devices Licenses
Enable TLS JA3 fingerprinting

service firewall <id> validator-timeout <u32>

Devices Licenses

Values:

u32 –
Validator timeout, in seconds

The validator is a process that ensures the firewall is up and running, there is at least one valid rule, and the configuration makes sense (in the firewall’s context). By default, it will wait up-to 5 minutes (300 seconds) for the OK message to appear. However, it can happen that such a message will take longer than that: - If the log level is different than “notice” (or any lower value), it won’t be logged. - If there are plenty of rules, it may take more than the given time. Adjust this value accordingly to the number of rules that are going to be used.