Close menu

Device control with Allow/Block/Quarantine (ABQ)

Device control with Allow/Block/Quarantine (ABQ)
Mobile devices connected to the server can have their access controlled specifically using the “Allow/Block/Quarantine” option. As a “pre-emptive” security measure, it responds to the first connection to the server and is designed to make sure that only authorised devices may complete synchronisation with the server. A complete administrator is now able to monitor every mobile device connected to their network. Only CLI tools are available for now.
 
If ABQ will start alongside Carbonio at startup is determined by the global Boolean parameter abq_enabled_at_startup. Although the property is set to true by default, it is advised to change it to false if it isn’t being utilised to conserve server resources.
 
Run the following command, then restart  mailboxd:, to disable the ABQ:
# carbonio config set global abq_enabled_at_startup false

The result of carbonio mobile getServices, should show ABQ as not operating (i.e., the value for ABQ’s running property should be false) to confirm that ABQ was deactivated.

Components
There are three basic logical parts that make up the ABQ feature:
  • Unified Device Control List
  • authorising engine
  • the CLI toolset

Device Control List

The Device Control List, also known as the “ABQ List”, holds the information about allowed devices within the config engine. Devices can be added to the Device Control List via CLI based on their “Device ID” which can be obtained via CLI.

It is also possible to further limit access by limiting the accounts that can synchronise with the server on a specific device.

Note

On module startup, if the Device Control List is empty all mobile devices previously recognized by the Carbonio server will be imported as Allowed.

Authorization Engine

The Authorization Engine takes care of checking devices against the Device Control List and setting their ABQ status to the appropriate value.

Each rule is applied to all accounts connecting using a device it is a device id. It applies to a specific account connecting using that device if it has the format device_id/account_id or device_id/accountName

CLI Toolset.

The CLI Toolset allows administrators to interact with the device control list and with the synchronization status of a device, specifically to:

  • Display the Device Control List

  • Display all Quarantined and Blocked Devices

  • Add one or more devices to the Device Control List

  • Move a device from “Quarantine” to “Allowed” or “Blocked”

  • Change the synchronization status of a device

In an ABQ-enabled environment, whenever an administrator changes a device’s status, the device will be forced to re-sync folders with the server depending on the issued state, causing an immediate re-route to either a Dummy Data that will explain what has happened to the user, or to the real mailbox to perform the re-sync.

Modes AB
Every time a mobile device tries to synchronise with the server, the ABQ function is activated. It may be configured to one of four potential modes: “Permissive,” “Interactive,” “Strict,” or “Disabled.” This characteristic applies to every cluster and is global.
Interactive

After authenticating the user and checking their account status for safety reasons, the Device Control system will check the “Device ID” sent by the device against the list of allowed devices:

  • if the device/user couple is in the “allowed” list the synchronization will continue.

  • if the device/user couple is not in the device list but device is in the “allowed” list the synchronization will continue.

  • if the device is not in the “allowed” list the synchronization will be paused, a dummy email notifying the user of its “Quarantine” status will be sent and the connection will be set to “Quarantine” status.

Administrators can be notified at regular intervals, and every notification email will only include new Quarantined devices. They will then be able to allow or deny the synchronization for each device using the appropriate CLI tools.

Strict

After authenticating the user and checking their account status for safety reasons, the Device Control system will check the “Device ID” sent by the device against the list of allowed devices:

  • if the device/user couple or the device by itself is in the “allowed” list the synchronization will continue.

  • if the device is not in the “allowed” list the synchronization will be put in “Blocked” state, no data will be synchronized and a dummy email notifying the user of the device’s “Blocked” status will be sent.

Permissive

The Authorization Engine is not active, so after authenticating the user and checking their account status for safety reasons, the synchronization will continue. It is still possible to block specific devices but non-blocked devices will always be allowed to sync.

Disabled

ABQ is disabled, no checks are triggered and no policies are enforced.

Mode Control for ABQ
The following command should be used to check the mode:
# carbonio config global get attribute abqMode

The following command can be used to switch the ABQ mode:

# carbonio config global set attribute abqMode value [Permissive|Interactive|Strict|Disabled]
Dummy Data
Dummy Data is a feature that uses fake emails and a fake mailbox to block devices in permissive, interactive, and strict modes or to put them on hold while waiting for authorization (Interactive Mode).
 
Dummy Emails are predetermined email messages that are synced to a device in Quarantine or Block state to inform the user, whilst the Dummy Mailbox is a virtual mailbox consisting solely of an Inbox folder that will be synchronised to the device when this is in either Quarantine or Block status. The sync state of a device is reset each time its ABQ status is altered.

Note

Currently, Dummy email messages can not be customised.

Dummy data have been included to ensure that the user is aware of what is occurring because the alternative would be to force the synchronisation to fail without providing the user with a descriptive answer, which would likely result in a major increase in support calls.

Custom ABQ E-mails

With the  carbonio mobile setABQMessage message command, simulated emails may be quarantined and blocked. Messages can be tailored at the global or domain level, and several languages can be set.

Setup Example

Given two files, /tmp/quarantine_body.txt and /tmp/quarantine_body.html containing the French language plaintext and html message bodies and the support@example.com support email address, the following command will set the quarantine message for the example.com domain without affecting other domains or users:

# carbonio mobile setABQMessage domain example.com quarantined fr from support@example.com body_plain_file /tmp/quarantine_body.txt body_html_file /tmp/quarantine_body.html``

Warning

Before being able to customize the ABQ messages, a default must be set using default as the language in the command, e.g., carbonio mobile setABQMessage global quarantined default

Notifications
Email notifications about quarantined devices can be sent to administrators at predetermined intervals determined by the abqNotificationsInterval configuration property, which is represented in milliseconds:
 
The following command may be used to check the interval:
# carbonio config global get attribute abqNotificationsInterval

The following command can be used to modify the interval:

# carbonio config global set attribute abqNotificationsInterval value [delay in milliseconds]

The abqNotificationsInterval is typically set to 0, which means that no notifications will be sent.

Service Status for ABQ
The following command may be used to verify the status of the ABQ service:
# carbonio mobile getServices

Using the Mobile module’s default service control, the service may be started or stopped:

# carbonio mobile doStartService abq
# carbonio mobile doStopService abq

Devices are always permitted to sync when mode is Disabled since the ABQ service is not launched automatically.

ABN QCL
Three Rule commands ( deleteRule, listRules, and setRule)) are part of the ABQ’s own set of CLI commands. With the exception of accepting regular expressions that adhere to the Java regex patterns standard (ERE with doubled backslashes), they have the same syntax as their equivalent delete, list, and set commands.
 
allow 
A particular command for a device in quarantine that changes the device’s status to Allowed.
 
block
A particular command for quarantined devices that changes the status of the device to Blocked.
 
Delete everything.
Rule Add or remove a device from each list.
 
import
This command imports a list of device IDs from a file and always needs two inputs: the “status” that the imported device(s) should be set to and an input file containing a list of device IDs separated by newlines.
 
Given the content of the file /tmp/list
androidc133785981
androidc1024711770
SAMSUNG1239862958/user@example.com,

the command:

# carbonio mobile abq import /tmp/list Allowed
Androidc133785981 and Androidc1024711770 can synchronise with any account thanks to the feature called “Allowed,” however device SAMSUNG1239862958 can only synchronise the user@example.com account.
 
the two lists Rules
List the ABQ status of all devices. Only devices with that particular state will be displayed in the list thanks to the “status” argument’s filtering. 
devices
       device_id   androidc133785981
       status      Quarantined

       device_id   androidc1024711770
       status      Blocked

       device_id   SAMSUNG1239862958
       status      Allowed
Typical output is set and  setRule
For each single device (known or unknown), set any status.
setNotificationInterval
Set the time between notifications for newly quarantined devices.