iboss integration

The Block in iboss rule response adds each IOC domain a matched rule cites to a dedicated iboss blocklist policy layer for your organization. Entries do not expire: a domain stays blocked until newer IOCs push it out of the layer or an administrator removes it. The layer applies to all users, so iboss blocks those domains wherever its gateway enforces policy. The rule decides which alerts trigger the response. Connecting an API key alone blocks nothing.

Prerequisites

• iboss version 10.1 or later, which issues API keys.
• An iboss administrator who can create an API key for the account.
• A cloud-hosted iboss gateway. On-premises gateways are not supported: Have I Been Squatted reaches only public iboss cloud hosts.
• The network enforcement add-on on the Have I Been Squatted organization, and an organization admin to configure it.

Create an API key

1. In the iboss console, create a dedicated administrator for Have I Been Squatted, for example Have I Been Squatted, with a role that can view and edit Policy Layers and nothing else your iboss edition lets you leave out.
2. Create an API key for that administrator. iboss shows the key once; copy it. Note when it expires.
3. Note the cloud you sign in to: api.ibosscloud.com or cloud.iboss.com.

An API key belongs to exactly one iboss account, and it can do whatever its administrator’s role allows, not only what Have I Been Squatted needs. Have I Been Squatted therefore limits itself: it creates or adopts one policy layer and only changes or removes entries in it whose note marks them as its own.

Connect

1. In the app, open Connectors > iboss.
2. Select the iboss cloud and paste the API key.
3. Select Connect.

The key is stored server-side and never returned to the browser. Connecting:

1. Reads your account settings on the selected cloud, which validates the key.
2. Reads the account’s clusters to find its primary gateway, and refuses one that is not a host under ibosscloud.com or iboss.com.
3. Looks for a blocklist policy layer named exactly haveibeensquatted-<organization id>-iocs. If there is none, it creates one, enabled and linked to all users.
4. Reads the layer’s settings and entries back to confirm the key can use it.

The connection is saved only when every step passes. The settings page shows the account, the layer, the gateway and, when iboss reports it, when the key expires. To use a new key, paste it and select Reconnect; rule responses are kept.

Connection check

Test connection repeats the first two steps, checks that the key still belongs to the connected account, and reads the layer’s settings and entries. It changes nothing. A failing check pauses blocking until a later check passes.

Result	Meaning
Authentication	iboss rejected the API key. It may be wrong, expired or revoked.
Wrong cloud	The key belongs to the other iboss cloud. The message names it.
Account changed	The key now belongs to a different iboss account. Connect again with a key for the original one.
Permission missing	The key’s role cannot read or edit policy layers.
Subscription missing	iboss refused the request, which usually means the account does not include policy layers.
Unsupported gateway	The account’s gateway is not an iboss cloud host. Only cloud-hosted gateways are supported.
Layer missing	The organization’s IOC layer was deleted. Connect again to recreate it.
Layer disabled	The layer is disabled in iboss. Enable it under Policy Layers and test again.
Layer unusable	A layer with that name exists but is not a block list, or a new layer’s settings did not save.
Rate limited	iboss throttled the check. Test again in a minute.
Unreachable	iboss timed out or returned a server error. Test again later.

What Have I Been Squatted creates

One blocklist policy layer, enabled and linked to all users, named:

haveibeensquatted-<organization id>-iocs

The organization id is Have I Been Squatted’s identifier for your organization, so each organization, and each Have I Been Squatted deployment, gets its own layer even when they share one iboss account. Keep the name: a reconnect finds the layer by it. An existing layer with that name is adopted as it is, so you can scope it to policy groups in the iboss console and the scope stays. Have I Been Squatted does not change any other policy layer or policy group.

Add the response to a rule

1. Create or edit a rule and open the Response tab.
2. Select Add action > Block in iboss.
3. Select the iboss destination.
4. Save the rule.

The destination is listed only while the connection’s last check passed. The response needs at least one domain condition in the rule, because only cited domain records produce entries.

What is sent

For each active rule alert that cites domain records, Have I Been Squatted reads the layer’s entries, then for each distinct cited domain, up to 10 per alert:

• No entry for the domain: adds one.
• An entry of ours: moves it to the head of the queue, in place (see the queue).
• An entry of yours, or one iboss reports already covers the domain: leaves it and records the domain as covered.

Each added entry is:

Field	Value
url	The cited IOC domain
timedUrl	0: the entry never expires
note	Marks the entry as Have I Been Squatted’s and records when it was last cited
direction	Both
Ports, regex, keyword	All ports, not a regex, no keyword

After the changes, Have I Been Squatted reads the layer back and checks each added or re-cited entry is there with its note.

• Only domains from cited domain (permutation) records are sent.
• The monitored domain and its subdomains are never sent.
• Email and canary evidence never produce entries.

Ownership

Every entry Have I Been Squatted adds carries a note such as:

haveibeensquatted:1;rule=<rule id>;seen=<unix seconds> | IOC blocked by a Have I Been Squatted rule

The note is the only thing that marks an entry as Have I Been Squatted’s: it starts with haveibeensquatted:, and seen is when a rule last cited the domain, in Unix seconds. Leave notes in place. An entry without that prefix is treated as yours: it is never changed or removed, and it does not count toward the cap, even when it names a domain a rule flags. A response dispatched by hand records dispatch=<dispatch id> in place of the rule.

The queue

Entries never expire, because an expiring block could lift just before a malicious domain is used again. Instead, Have I Been Squatted keeps at most 1,000 entries of its own in the layer, as a queue ordered by seen:

• A new domain joins the head of the queue.
• When the queue is full, each new domain removes the entry of ours least recently cited, from the tail. An entry whose note has no readable seen counts as the oldest.
• A domain cited again moves back to the head, so an IOC that rules keep citing is not the one removed.

Moving an entry to the head rewrites its note in place, with iboss’s entry update, so the domain is never unlisted. To avoid a policy change in your layer on every alert, an entry is rewritten only when it was last cited more than a day ago, or when it is among the next 100 entries the queue would remove. If iboss refuses the rewrite, the entry keeps blocking where it is in the queue. If the read-back finds the rewrite lost the entry, Have I Been Squatted adds it again at once.

Additions are sent before removals, so a delivery that stops early has removed nothing. Such a delivery can leave a few more than 1,000 entries of ours in the layer: each later addition still removes only one.

If iboss refuses one domain, the others are still sent. If iboss rejects the key, times out or returns a server error, the remaining domains are not sent and the delivery is not retried. A throttled request is sent once more when iboss asks to wait ten seconds or less.

What is recorded

Have I Been Squatted stores the cloud, the API key, the account, the gateway, the layer, when the key expires, and the time and outcome of the last connection check. For each alert and response, it records the delivery status, the domains added, moved to the head, already current, covered, refused, removed from the tail or not sent, and, when a delivery fails, a short error code. The session cookies iboss issues during a delivery are discarded when it ends. iboss response bodies are not stored.

Disable and disconnect

Disable stops new entries and keeps the connection and rule responses. A passing connection test turns blocking back on.

Disconnect deletes the stored key and removes the Block in iboss response from every rule, along with those responses’ delivery records.

Neither action deletes the layer or its entries, and entries do not expire, so they keep blocking. When you no longer want them, delete the haveibeensquatted-<organization id>-iocs layer, or the entries whose note starts with haveibeensquatted:, in the iboss console. To stop blocking at once, disable the layer there. To revoke access, delete the API key in the iboss console.

Limits

• Each delivery makes up to 23 requests for 10 domains: one to open a session, two reads of the layer, an addition or a note rewrite per domain, a removal per addition when the queue is full, and a re-addition per rewrite the read-back lacks.
• Entries block domains only, on all ports. They are not regular expressions and do not cover URLs.
• iboss does not publish a policy layer size, rate limit or propagation time. A change may take a short time to reach every gateway.
• An entry cited again within a day of its last note rewrite keeps its place in the queue, unless it is among the next 100 the queue would remove.

Note

Only organization admins can view or change the iboss connection.