SIEM Integration

What Is SIEM Integration?

SIEM Integration adds the decision that Bot/DDoS protection makes for a request to the HTTP access log as a single JSON object and carries this log to the SIEM system over syslog. The object is added to the log profile with the %THREAT_INFO variable (named Bot/DDoS Protection Detail in the interface) and is produced in the same shape for every request: which protection made the decision, the applied action, the bot score and class, the triggered L7 DDoS rule and the measured value, the IP reputation category, the TLS and User-Agent identity of the client, exemptions and quarantine information are all in the same object.

As a result, Bot/DDoS events are read on the SIEM side on the same line as the rest of the access log (time, client address, request, response code); there is no need to define a separate event source or to export the Event Logs screen in the TR7 interface.

Single Variable

%THREAT_INFO

The whole Bot/DDoS decision in a single JSON object

Fixed Shape

Same on every request

All keys are always present; empty ones are written too

Typed Values

Number and flag

Numbers are JSON numbers or null, flags are true/false

summary

One-sentence summary

A one-sentence English explanation of the decision

Produced on every request

The object is produced for every request on vServices whose log profile uses %THREAT_INFO; it is written not only for blocked requests but also for passed, monitored and exempted requests. If the vService has no Bot/DDoS protection, or the request is dropped by a rule outside Bot/DDoS, the variable is not produced. The repetition limiting (thinning of the same event) on the Event Logs screen is not applied to this variable.

How to Set It Up?

1

Step 1 Create the log profile

Load Balancer → Profiles → Logs: on this screen a new log profile is added or an existing profile is edited. In the Line Format field, one of the three Manual formats is selected: Manual JSON Format, Manual CEF Format or Manual Log Line Format. Manual JSON Format is recommended so that the fields can be parsed directly in the SIEM; in the other two formats the object is written as text (see Output by Log Format). For the general fields of the profile, see the Logs page.

2

Step 2 Add the %THREAT_INFO variable

In the Manual JSON Format and Manual CEF Format formats, a row is added to the Manual Log Entries table and the key name to be used on the SIEM side (e.g. Bot-DDOS) is written in the Key field. The Value cell of the new row comes filled with the first variable not yet used in the list. Clicking the variable label in the cell opens the Edit Variable window; the Variable Name list is filtered by typing Bot/DDoS and the Client Info - Bot/DDoS Protection Detail option is selected.

In the Manual Log Line Format format, the variable is added at the desired place in the line template: the fx button to the right of the template field opens the Add Variable window and the variable is selected from the same list. %THREAT_INFO text typed manually into the template also turns into a variable label shortly after typing ends. For details, see the Smart Variables page.

The other fields of the access log (time, client address, host, request, response code, User-Agent header) are added with separate variables; %THREAT_INFO does not carry this information.

3

Step 3 Define the log server

The address and port (IP:Port) of the SIEM's syslog receiver is entered in the log address field of the profile; the transport protocol (UDP or TCP) and the log standard are selected. If every record is required to reach the SIEM, Sampling is left disabled; when enabled, only part of the records is sent.

4

Step 4 Assign the profile to the vService

The profile is selected as the log profile in the edit form of the HTTP vService. The steps are described in the How to Add to a vService? section of the Logs page.

5

Step 5 Parse on the SIEM side

With Manual JSON Format, the log line is parsed as JSON in the SIEM; the Bot/DDoS information is read as a nested object under the key given in the second step (e.g. Bot-DDOS). If a log standard that adds a syslog header is selected, the SIEM must strip this header before the JSON.

The outer key name belongs to the user

The key under which the object is placed is set in the Key field. The examples on this page use Bot-DDOS; any name that fits the field naming convention in the SIEM is given.

The Value field must contain only %THREAT_INFO

For the value to be written as a JSON object, the Value cell must contain nothing other than %THREAT_INFO. If text or a converter is added to the variable, the output is written as a text containing escaped JSON instead of a nested object, and a second parsing is needed in the SIEM.

Output by Log Format

%THREAT_INFO is used only on HTTP vServices and in all three of the Manual formats; the formats differ only in the shape of the output. Fixed log formats do not carry this variable.

Line Format	%THREAT_INFO output
Manual JSON Format	Nested JSON object. If the variable is not produced at all (e.g. the vService has no Bot/DDoS protection), the value of the key is null. This is the recommended format.
Manual CEF Format	Escaped JSON text; per the CEF rule, = characters are written as \=. On HTTP vServices the field is always written; on L7 TCP vServices, where the variable cannot be used, the field is not added to the line at all.
Manual Log Line Format	The JSON text is written into the line as is.
Standard Log Format, Apache Combined, Apache VHost, CEF Format, TR7 JSON Format, TR7 WAF Log	The variable cannot be used.

Exception to the "all values are text" rule in Manual JSON

In the Manual JSON Format output, values are normally printed as text in double quotes. Only a row containing %THREAT_INFO is outside this rule: the value is written as an object, and the numbers inside the object come as JSON numbers and the flags as true/false.

Sample Record

The record below is taken from a Manual JSON profile whose Key field is Bot-DDOS. While the Source IP Request Protection rule of L7 DDoS protection was running in Monitor mode, a source exceeded the request rate limit; had the protection been in Enforce mode, it would have shown a CAPTCHA.

The record that reaches the SIEM is a single line:

{"Bot-DDOS":{"action":"monitored","module":"","summary":"monitored: ddos would apply captcha","monitor":{"module":"ddos","action":"captcha"},"bot":{"score":23,"class":"clean","threshold":null,"factors":"secFetchAbsent;pathHammering;clientHintMismatch;"},"ddos":{"rule":"sR","observed":80,"limit":3},"ipReputation":{"category":""},"client":{"ja4":"","ja4Family":"","ja4Match":"","uaFamily":"chromium","networkType":""},"exempt":{"ddos":false,"bot":false,"ipReputation":false},"captchaFails":"","quarantinedBy":"","ceilingDrop":false}}

The same record, indented for readability:

{
  "Bot-DDOS": {
    "action": "monitored",
    "module": "",
    "summary": "monitored: ddos would apply captcha",
    "monitor": {
      "module": "ddos",
      "action": "captcha"
    },
    "bot": {
      "score": 23,
      "class": "clean",
      "threshold": null,
      "factors": "secFetchAbsent;pathHammering;clientHintMismatch;"
    },
    "ddos": {
      "rule": "sR",
      "observed": 80,
      "limit": 3
    },
    "ipReputation": {
      "category": ""
    },
    "client": {
      "ja4": "",
      "ja4Family": "",
      "ja4Match": "",
      "uaFamily": "chromium",
      "networkType": ""
    },
    "exempt": {
      "ddos": false,
      "bot": false,
      "ipReputation": false
    },
    "captchaFails": "",
    "quarantinedBy": "",
    "ceilingDrop": false
  }
}

The record is read as follows:

• action monitored: the request was passed, but a protection in monitor mode would have applied an action. Since no action was applied, module is empty.
• monitor states which protection would have done what: the captcha action of the ddos protection.
• ddos gives the triggering rule and the values: sR (Source IP Request Protection), measured 80, limit 3.
• bot carries the bot score for the same request: 23, class clean. Three factors were triggered; since no bot rule matched, threshold is null.
• client.uaFamily chromium: the User-Agent header indicates a Chromium browser. The JA4 fields are empty: the connection is not TLS, or there is no setting on this vService that requires JA4 calculation.
• All exempt flags are false: the client is not on the whitelist of any protection.

Field Descriptions

All keys of the object are present in every record. Text fields with no value are written as empty text (""), number fields as null, flags as false. Text values are the engine's own codes, not the labels in the interface; the tables below give the interface equivalents of the codes.

Decision Fields

Field	Type	Description
action	text	What happened to the request. Never empty. Its values are in the table below.
module	text	The protection that made the decision: ddos, ipRep, bot or quarantine (if the client is in the quarantine box). Empty when no action was applied (monitored, whitelisted, trustedBot, passed) and on a hard ceiling drop (ceilingDrop true). Its interface equivalent is Handled By.
summary	text	A one-sentence English summary of the decision. Its templates are in the table below.

action Values

Value	Meaning	Action cell in Event Logs
block	The request was blocked (the response code is defined in the action rule).	Blocked
tarpit	The response was given after a delay.	Tarpitted
redirect	The client was redirected to another address.	Redirected
showContent	Custom content was shown.	Content shown
captcha	A CAPTCHA challenge was shown.	CAPTCHA shown; on the challenge response Captcha solved or Captcha failed
silentDrop	The connection was closed without a response.	Silently dropped
quarantine	The client is in the quarantine box; the request was turned away by the box.	Blocked by quarantine
monitored	A protection in monitor mode would have applied an action; the request was passed. Details are in the monitor object.	Would … (e.g. Would show CAPTCHA) · Monitor
whitelisted	The client is on the whitelist of a protection; the request was passed. Which protection exempted it is in the exempt object.	Allowed · Whitelist
trustedBot	The client is a verified bot (crawler); the request was passed.	Allowed · Trusted bot
passed	No protection intervened.	Usually no row is written; for a request exceeding the score floor Allowed · Insufficient score

summary Templates

The summary is produced with one of the templates below according to the action value and the protection that made the decision; for applied actions the order by protection is bot, L7 DDoS, IP reputation, quarantine. <action> is replaced with the value of the action field, and the other expressions in angle brackets with the values of the related fields.

Case	Template	Example
The action of bot protection was applied	<action>: bot score <score> reached threshold <threshold>	block: bot score 91 reached threshold 85
The action of an L7 DDoS rate/count rule or of a limited country/network type row was applied	<action>: ddos rule <rule> exceeded (<observed>/<limit>)	captcha: ddos rule sR exceeded (80/3)
The action of an unlimited (membership only) country or network type row in L7 DDoS was applied	<action>: ddos rule <rule> matched	block: ddos rule c0 matched
The action of IP reputation protection was applied	<action>: ip reputation category <category>	block: ip reputation category hacking
The client is in the quarantine box	<action>: source is in quarantine	quarantine: source is in quarantine
The hard ceiling was exceeded	silentDrop: ceiling limit <rule> exceeded (<observed>/<limit>)	silentDrop: ceiling limit hardTotalReq exceeded (5200/5000)
An applied action other than the above	<action>	block
A protection in monitor mode would have applied an action	monitored: <protection> would apply <action>	monitored: ddos would apply captcha
Whitelist exemption	whitelisted: exempt by whitelist
Verified bot	trustedBot: verified crawler
Passed, bot score present	passed: bot score <score> (<class>)	passed: bot score 23 (clean)
Passed, no bot score	passed

monitor (Monitor Mode)

Field	Type	Description
monitor.module	text	The protection that would apply an action in monitor mode: ddos, ipRep or bot.
monitor.action	text	The action that would be applied; its values are the same as the applied actions in the action table (block, captcha, tarpit, redirect, showContent, silentDrop, quarantine).

This object is filled when a protection running in Monitor mode has a matching rule; if more than one protection matches in monitor mode, the first protection in priority order (ddos, ipRep, bot) is written. If there is no match in monitor mode, both fields are empty. Its interface equivalent is Monitor Mode.

bot (Bot Protection)

Field	Type	Description
bot.score	number | null	The bot score of the request between 0 and 100. null if Bot Protection is not enabled.
bot.class	text	The class the score falls into (table below). Empty if there is no score.
bot.threshold	number | null	The score threshold of the matched bot action rule. Written even if the rule matched in monitor mode; null if no bot rule matched or another protection made the decision (or the monitor record).
bot.factors	text	The codes of the factors contributing to the score, as a list separated by ; and ending with ;. Empty if no factor was triggered.

bot.class	Score range	Class in the interface
clean	0–39	Clean
suspicious	40–59	Suspicious
likely_bot	60–84	Bot
bot	85–100	Bad Bot

The bot code is the "Bad Bot" class

The codes and the class names in the interface do not match one to one: the bot code is displayed as Bad Bot in the interface, and the likely_bot code as Bot. This difference must be taken into account when writing alarm rules in the SIEM.

The codes in the bot.factors list are the sub-items of the factors on the Factors page. The codes by factor group are as follows:

Factor group	Codes
Infrastructure & IP Reputation	datacenterIp, torExit, openProxy, badBot, attack, recon, spam, vpnIp, botnetHost, fraud, dnsAbuse, operatorBlacklist
Identity Spoofing Detection	botUa, notBrowser, headlessBrowser, crawlerImpersonation
Network Fingerprinting	deprecatedVersion, noAlpn, weakCipher, malwareJa3, botJa4, ja4ToolImpersonation
Protocol Hygiene	emptyHost, missingHeaders, secFetchAbsent, weirdAcceptHeader, httpVersion, protocolMismatch
Cross-Signal Consistency	tlsUaMismatch, httpCookieMismatch, clientHintMismatch
Behavioral Analysis	pathHammering, rapidRequests, highNotFoundRate, noRefererOnMutation, scannerMethod, suspiciousPath
Client Evidence	ceAutomationDeclared, ceAutomationInferred, ceEngineMismatch, ceFormTiming, ceBehavioral, ceTrapSprung
Human Verification	agsLoggedIn, captchaTicket, ceHumanInteraction

The codes in the Human Verification group do not change the bot.score value; they indicate the reduction applied to the score used in the action decision for a client verified as human. The list contains the factors selected in the Bot Protection settings that fit the protocol of the vService; Human Verification codes, however, are written whenever the related verification takes place, regardless of the selection.

ddos (L7 DDoS Protection)

Field	Type	Description
ddos.rule	text	The code of the triggered L7 DDoS rule (table below). Written if the rule was triggered, whether the protection is in Enforce or Monitor mode; empty if no rule was triggered. If the source exceeded the hard limit of the source IP limit and entered quarantine, the quarantine makes the decision and this field may stay empty.
ddos.observed	number | null	The value measured at the moment the decision was made.
ddos.limit	number | null	The limit of the rule.

Country and network type rows with no limit defined (checking membership only) do not measure a counter, so observed and limit are null on these rows; on limited rows both fields are filled. Their interface equivalents are DDoS Rule and Trigger (Value / Limit).

ddos.rule	Rule
sR	Source IP Request Protection
sC	Source IP Connection Protection
err	Source IP Error Protection
tR	Total Request Protection
tC	Total Connection Protection
tA	Active Source-IP Protection
c0, c1, …	Country Control rule row. Numbering starts at zero: c0 is the 1st row in the interface.
n0, n1, …	Network Type Group Control rule row. Numbering starts at zero: n0 is the 1st row in the interface.
hardTotalReq	The hard limit of Total Request Protection (Hard Ceiling in the interface)
hardTotalConn	The hard limit of Total Connection Protection (Hard Ceiling in the interface)

ipReputation (IP Reputation Protection)

Field	Type	Description
ipReputation.category	text	The IP reputation category the source address is in; if it is in more than one category, the first match according to the order of the action rules is written. Filled while IP Reputation Protection is in Enforce or Monitor mode; also written when the request is not blocked (whitelist, verified bot or no matching rule). Empty if the address is in none of the categories used in the action rules.

Code	Category	Code	Category
user	User Blacklist	external	External
dnsCompromise	DNS Compromise	dnsPoisoning	DNS Poisoning
fraudOrders	Fraud Orders	dDoSAttack	DDoS Attack
ftpBruteForce	FTP Brute-Force	pingOfDeath	Ping of Death
phishing	Phishing	fraudVoIp	Fraud VoIP
openProxy	Open Proxy	webSpam	Web Spam
emailSpam	Email Spam	blogSpam	Blog Spam
vpnIp	VPN IP	portScan	Port Scan
hacking	Hacking	sqlInjection	SQL Injection
spoofing	Spoofing	bruteForce	Brute-Force
badWebBot	Bad Web Bot	exploitedHost	Exploited Host
webAppAttack	Web App Attack	ssh	SSH
ioTTargeted	IoT Targeted

The descriptions of the categories are on the IP Intelligence & Reputation page.

client (Client Identity)

Field	Type	Description
client.ja4	text	The raw JA4 TLS fingerprint of the client. Filled only on TLS connections, when the device has JA4 support and a setting that uses JA4 (the JA4 factors of Bot Protection, a JA4 whitelist entry or the %JA4 variable) exists. Its interface equivalent is JA4 (Raw).
client.ja4Family	text	The TLS stack family the JA4 fingerprint belongs to (list below). Empty if the fingerprint is not recognized or the device has no JA4 support. Its interface equivalent is TLS Fingerprint (JA4).
client.ja4Match	text	Which match the family was found with: e exact JA4 match, c cipher suite level match. Empty if there is no match. It does not show whether TLS and the User-Agent are consistent; this inconsistency is reported by the tlsUaMismatch or ja4ToolImpersonation factor.
client.uaFamily	text	The browser or tool family claimed by the User-Agent header (list below). Empty if the User-Agent fits no pattern or the device has no JA4 support. Its interface equivalent is User-Agent Claim.
client.networkType	text	The network type group of the source address (table below). Empty if the address cannot be classified (e.g. private address ranges). Its interface equivalent is Network Type.

client.ja4Family values: chromium, firefox, safari, curl, wget, python, go, java, node, postman, dotnet, ruby, php, rust, schannel, openssl, cfnetwork and the generic tool used when more than one tool shares the same fingerprint.

client.uaFamily values: crawler, curl, wget, python, go, java, cfnetwork, node, postman, dotnet, ruby, php, rust, safari, chromium, firefox; none when the User-Agent header is empty and the tlsUaMismatch factor is selected in Bot Protection.

client.networkType	Network type	client.networkType	Network type
aws	Amazon AWS	linode	Linode
azure	Microsoft Azure	vultr	Vultr
gcp	Google Cloud	leaseweb	LeaseWeb
oracle	Oracle Cloud	scaleway	Scaleway
alibaba	Alibaba Cloud	contabo	Contabo
tencent	Tencent Cloud	hosting	Generic Hosting
huawei	Huawei Cloud	cdn	CDN
ovh	OVH	verified_bot	Verified Bot
hetzner	Hetzner	tor	Tor Exit Node
digitalocean	DigitalOcean	residential	Residential
		mobile	Mobile / CGNAT

The network type is checked on every request

client.networkType is filled on every request; it stays empty only for addresses that cannot be classified in the network type database.

exempt (Exemptions)

Field	Type	Description
exempt.ddos	true | false	The client is on the whitelist of L7 DDoS protection.
exempt.bot	true | false	The client is on the whitelist of Bot Protection.
exempt.ipReputation	true | false	The client is on the whitelist of IP Reputation Protection.

The flags become true when the protection's own whitelist condition or entries match. The own exemptions of the country and network type rule rows in L7 DDoS do not change the exempt.ddos flag.

Additional Fields

Field	Type	Description
captchaFails	text	The number of failed CAPTCHA attempts within the tracked period and the quarantine threshold, in n/threshold form (e.g. 2/3). Written only on a request whose CAPTCHA response failed and when failed solutions are tied to quarantine on the Captcha card; empty on other requests. The value is text, not a number.
quarantinedBy	text	The mechanism that sent the client to the Quarantine box with this request (table below). Written only on the request at the moment of entering the box; empty on subsequent requests the client sends while in the box.
ceilingDrop	true | false	true if the request was dropped without a response because the hard ceiling of the total request or connection rate was exceeded. In this case action is silentDrop. The hard ceiling is applied only while the protection is in Enforce mode and a hard limit is defined in Total Request or Total Connection Protection; it is not applied to clients on the L7 DDoS whitelist.

quarantinedBy	Mechanism
ddos	L7 DDoS source limit (DDoS Limit)
bot	Bot score (Bot Score)
ipRep	IP reputation rule (IP Reputation)
captcha	Failed CAPTCHA solutions (Failed Captcha)

Decision Logic

More than one protection may be triggered on a request; only the action of the winning decision is written to the object. Evaluation is done in the following order:

01 · QuarantineQuarantine boxA client in the box is turned away directly

02 · ddosL7 DDoS ProtectionVolume and country/network type rules

03 · ipRepIP Reputation ProtectionKnown bad addresses

04 · botBot ProtectionBehavioral bot score

• The first one wins. For a client in the quarantine box, the box always makes the decision and module is quarantine; the protections still run and write their measurements to the object. On the request where a rule sends the client to the box, the box also makes the decision. On a request not in the box, the action applied by L7 DDoS takes precedence over the actions of IP reputation and bot. The measurements of the losing protections are still written to the object: even if L7 DDoS wins, bot.score and ipReputation.category may come filled.
• Order within L7 DDoS: country rule, network type rule, source IP request and connection limits, error limit, total limits, active source count.
• Monitor mode does not win. A protection in Monitor mode does not apply an action, so it is not written to the module field; it only fills the monitor object. If more than one protection matches in monitor mode, only the first protection in priority order is written.
• If no action was applied, action is determined in this order: monitored, whitelisted, trustedBot, passed.
• Verified bot: trustedBot is written when the client's network type is verified_bot and one of the protections trusts verified bots. By default Bot Protection and IP Reputation Protection trust them, L7 DDoS does not.
• The hard ceiling is independent. The hard ceiling of the total request or connection rate is applied regardless of which protection wins; when exceeded, ceilingDrop is true and action is silentDrop. It is not applied to clients on the L7 DDoS whitelist.

Scenario Examples

The records below are shortened for readability: only the fields describing the scenario are shown; the real record contains all keys.

Block Due to Bot Score

{
  "action": "block",
  "module": "bot",
  "summary": "block: bot score 91 reached threshold 85",
  "bot": {"score": 91, "class": "bot", "threshold": 85, "factors": "botUa;notBrowser;missingHeaders;rapidRequests;"},
  "client": {"uaFamily": "python", "networkType": "hosting"}
}

With a bot score of 91, the request is in the Bad Bot class (bot code) and the action rule with threshold 85 matched. uaFamily and networkType show that the request came from a Python script running at a hosting provider.

CAPTCHA at the L7 DDoS Limit

{
  "action": "captcha",
  "module": "ddos",
  "summary": "captcha: ddos rule sR exceeded (240/100)",
  "ddos": {"rule": "sR", "observed": 240, "limit": 100}
}

The request rate of the source address is 240, the Source IP Request Protection limit is 100; the rule is in Enforce mode and showed a CAPTCHA.

Quarantine Due to IP Reputation

{
  "action": "quarantine",
  "module": "quarantine",
  "summary": "quarantine: source is in quarantine",
  "ipReputation": {"category": "hacking"},
  "quarantinedBy": "ipRep"
}

The address is in the Hacking category and the IP reputation rule put the client into quarantine. Since the box makes the decision also at the moment of entry, module is quarantine; quarantinedBy shows which protection sent the client to the box. quarantinedBy is filled only on this first request; on subsequent requests the client sends while in the box, it comes empty with the same module and summary.

Whitelisted Client

{
  "action": "whitelisted",
  "module": "",
  "summary": "whitelisted: exempt by whitelist",
  "exempt": {"ddos": false, "bot": true, "ipReputation": false}
}

The client is on the whitelist of Bot Protection; the request was passed. The bot score is still calculated and may appear in the bot object.

Verified Bot

{
  "action": "trustedBot",
  "module": "",
  "summary": "trustedBot: verified crawler",
  "client": {"uaFamily": "crawler", "networkType": "verified_bot"}
}

The address is in a range published by a verified bot (crawler); the request was passed.

Usage Tips in SIEM

Goal	Fields to use
All blocked requests	action value block, captcha, tarpit, redirect, showContent, silentDrop or quarantine
How much each protection intervened	Grouping by the module field
Measuring impact before switching to Enforce mode	action = monitored; grouping by the monitor.module and monitor.action fields
Bad bot density	bot.class = bot or likely_bot; together with client.networkType
L7 DDoS rule tuning	ddos.rule, ddos.observed, ddos.limit (how far the limit was exceeded)
Clients entering quarantine	Records with quarantinedBy filled (moment of entering the box); together with the client address
Capacity alarm	ceilingDrop = true
Whitelist audit	action = whitelisted and the exempt flags
Clients spoofing their identity	tlsUaMismatch, ja4ToolImpersonation or crawlerImpersonation in bot.factors; comparison of client.ja4Family with client.uaFamily

Scope and Limits

INFO

• %THREAT_INFO is used only on HTTP vServices and only in log profiles with a Manual format; it is not produced on L7 TCP and Network vServices.
• The variable is calculated for every request on vServices whose log profile uses it; the per-request processor cost is in the order of a few microseconds and affects only these vServices.
• The object does not carry the time, client address, host, request line, response code or raw User-Agent header (only the client.uaFamily family is present); these are added to the log profile as separate rows.
• Traffic dropped at the network layer before a request is formed (e.g. L4 DDoS Protection) does not enter the HTTP access log and is therefore not in this object.
• ddos.observed and ddos.limit carry only the values; the time window in which the limit is measured is not in the object and is read from the rule's own setting.
• bot.score and bot.class show the score without reduction. Human verification (Human Verification factors) lowers the score in the action decision; therefore a score above the lowest action threshold may be seen on a passed request.
• For a client in the quarantine box, action is written as quarantine; the configured response type of the box is not reflected in this field. If a client in the box hits the hard ceiling, action is silentDrop and ceilingDrop is true.
• Records are sent to the syslog addresses defined in the log profile; transport and format settings are managed from the Logs profile.