firewall

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

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

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

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> bypass action drop
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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

service firewall <id> bypass action drop set
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

Modify the packet and/or flow when a verdict takes place

service firewall <id> bypass action drop set connmark
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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.

service firewall <id> bypass action drop set connmark mark <u32>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

  • u32 – Set a connmark

service firewall <id> bypass action drop set connmark vrf-mark <id>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

Set connmark using a VRF

Reference:

system vrf <id>

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

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

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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

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

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

service firewall <id> hashset file <file>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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

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

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

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

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

Redis settings for EVE logging

Required:

service firewall <id> logging outputs eve redis async <bool>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

  • bool – Read Redis replies asynchronously

service firewall <id> logging outputs eve redis key <id>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

  • id – Key or channel to use

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

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

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

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

Syslog settings for EVE logging

Required:

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

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

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

Event types settings for EVE logging

service firewall <id> logging outputs eve types files
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

File info module settings for EVE logging

service firewall <id> logging outputs eve types files force-hash <id>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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

Alerts consisting only on a single line

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

Keep tracking of all HTTP requests

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

Save all packages registered by the firewall

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

Fast-like logging messages written to syslog

Required:

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

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

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

Line-based log of TLS handshake parameters

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

Supplementary information about an alert

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

Firewall logging rotation options

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

Enable compression of old log files using gzip

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

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

Firewall running mode

Instances:

Unique

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

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

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

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

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

service firewall <id> ruleset compressed <file>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

  • file – Compressed file containing

Instances:

Multiple

service firewall <id> ruleset compressed <file> digest <id>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

service firewall <id> ruleset compressed <file> encrypted-password <password>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

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

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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

  • file – File from which different rules will be loaded

Instances:

Multiple

service firewall <id> ruleset file <file> digest <id>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

service firewall <id> ruleset file <file> encrypted-password <password>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

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

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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

service firewall <id> ruleset patch <file> encrypted-password <password>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
Values:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

service firewall <id> stream bypass action drop set xdp-early-drop <ifc>
AresC640 Atlas840 M10-Smart M2 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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

Drop packets that are seen invalid by the stream engine

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

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

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

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

TLS detection enabling and configuration

service firewall <id> tls-detection detection-ports <u32>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE

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

Enable TLS JA3 fingerprinting

service firewall <id> validator-timeout <u32>
AresC640 Atlas840 M10-Smart M2 RS420 RXL15000 SDE
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.