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:
- 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.