firewall

service firewall <id>
SDE M10-Smart M2 RS420 AresC640
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:

Required:

service firewall <id> action-order <id>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640

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

service firewall <id> detect-thread-ratio <float>
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
Values:
  • u32 – Size of the hash-table used for organizing flows

service firewall <id> flow max-memory <id>
SDE M10-Smart M2 RS420 AresC640
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 prealloc <u32>
SDE M10-Smart M2 RS420 AresC640
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> logging
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

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

Values:
  • eve – JSON output for alerts and events

  • fast – Alerts consisting only on a single line

  • http – Keep tracking of all HTTP requests

  • pcap – Save all packages registered by the firewall

  • verbose – Supplementary information about an alert

  • tls – Line-based log of TLS handshake parameters

service firewall <id> logging outputs eve
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

Redis settings for EVE logging

Required:

service firewall <id> logging outputs eve redis async <bool>
SDE M10-Smart M2 RS420 AresC640
Values:
  • bool – Read Redis replies asynchronously

service firewall <id> logging outputs eve redis key <id>
SDE M10-Smart M2 RS420 AresC640
Values:
  • id – Key or channel to use

service firewall <id> logging outputs eve redis mode <id>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

Syslog settings for EVE logging

Required:

service firewall <id> logging outputs eve syslog identity <id>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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 fast
SDE M10-Smart M2 RS420 AresC640

Alerts consisting only on a single line

service firewall <id> logging outputs http
SDE M10-Smart M2 RS420 AresC640

Keep tracking of all HTTP requests

service firewall <id> logging outputs pcap
SDE M10-Smart M2 RS420 AresC640

Save all packages registered by the firewall

service firewall <id> logging outputs syslog
SDE M10-Smart M2 RS420 AresC640

Fast-like logging messages written to syslog

Required:

service firewall <id> logging outputs syslog identity <id>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

Line-based log of TLS handshake parameters

service firewall <id> logging outputs verbose
SDE M10-Smart M2 RS420 AresC640

Supplementary information about an alert

service firewall <id> logging rotation
SDE M10-Smart M2 RS420 AresC640

Firewall logging rotation options

service firewall <id> logging rotation amount <u32>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

Enable compression of old log files using gzip

service firewall <id> logging rotation periodic <id>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

Firewall running mode

Instances:

Unique

service firewall <id> mode inline
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

Set of rules to be used by the firewall when registering traffic

service firewall <id> ruleset compressed <file>
SDE M10-Smart M2 RS420 AresC640
Values:
  • file – Compressed file containing

Instances:

Multiple

service firewall <id> ruleset compressed <file> digest <id>
SDE M10-Smart M2 RS420 AresC640
Values:
  • id – If the ruleset is encrypted, digest used during key derivation

service firewall <id> ruleset compressed <file> encrypted-password <password>
SDE M10-Smart M2 RS420 AresC640
Values:
  • password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset compressed <file> file <txt>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
Values:
  • file – File from which different rules will be loaded

Instances:

Multiple

service firewall <id> ruleset file <file> digest <id>
SDE M10-Smart M2 RS420 AresC640
Values:
  • id – If the file is encrypted, digest used during key derivation

service firewall <id> ruleset file <file> encrypted-password <password>
SDE M10-Smart M2 RS420 AresC640
Values:
  • password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset file <file> iterations <u32>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
Values:
  • id – If the patch is encrypted, digest used during key derivation

service firewall <id> ruleset patch <file> encrypted-password <password>
SDE M10-Smart M2 RS420 AresC640
Values:
  • password – If the file is encrypted, the encrypted password used for decrypting it

service firewall <id> ruleset patch <file> file <txt>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

Engine statistics such as packet counters, memory use counters and more

service firewall <id> stats interval <u32>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

Attributes to set to a packet/flow whenever it is accepted

service firewall <id> stream bypass action accept set conntrack
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

Attributes to set to a packet/flow whenever it is dropped

service firewall <id> stream bypass action drop set xdp-early-drop <ifc>
SDE M10-Smart M2 AresC640
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 packages not even 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>
SDE M10-Smart M2 RS420 AresC640
Values:
  • id

    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 (kb, mb or gb - value must be lowercase).

service firewall <id> stream bypass mark <u32>
SDE M10-Smart M2 RS420 AresC640
Values:
  • u32

    Custom mark used when bypassing a packet

    Use bypass mark for implementing NFQ 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>
SDE M10-Smart M2 RS420 AresC640
Values:
  • u32

    Custom mask used when bypassing a packet

    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
SDE M10-Smart M2 RS420 AresC640

Set conntrack mark instead of packet mark

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
SDE M10-Smart M2 RS420 AresC640

Drop packets that are seen invalid by the stream engine

service firewall <id> stream inline <id>
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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
SDE M10-Smart M2 RS420 AresC640

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
SDE M10-Smart M2 RS420 AresC640

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>
SDE M10-Smart M2 RS420 AresC640
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> validator-timeout <u32>
SDE M10-Smart M2 RS420 AresC640
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.