Lawliet LAWLIET
Book a demo

54. Blocklist

This guide describes Lawliet 1.5.15.s (the current release). Screens, commands and procedures may change in later versions; the usage guide is updated with each release. Check the version your server runs under Settings > Platform or with ./lawliet version, and see the Releases page for what changed.

The blocklist is the one list of every address and network Lawliet blocks on hosts, whoever or whatever asked for it: a block made on this page, a decoy set to Auto-block source, a playbook step, an action from the Defense page, or an Under Attack activation. For each entry it shows where it applies (one host, or every host), until when, who asked and why, and what each host did with it.

Blocks are made with the agents' existing block and unblock actions (iptables/ip6tables on Linux, Windows Firewall rules on Windows, a pf anchor on macOS). Nothing is pushed to a network firewall from here.

The blocklist is part of the defense licence feature.

Permissions:

TaskPermissionFour-eyes
See the blocklist, an entry and its hosts; preview a blockView active defence-
Block an address at one host or at every hostExecute containmentyes - "Run a containment action"
Unblock an entry that applies to every host or to several hosts, or one made through Defense or a playbookExecute containmentyes - "Run a containment action" (as Defense > Undo)
Unblock a one-host entry made here or by a decoyExecute containmentno
Retry a host that failedExecute containmentno (it sends again what was already approved)
Preview a block (what is refused, protected and reached)Execute containment-

Four-eyes here follows the dual-control policy for Run a containment action, like every containment: with dual control off for that action (or before a second approver exists), an every-host block runs on one signature. Keep dual control on for it.


54.1 What is never blocked#

Every block path goes through the same check before anything is sent to a host. A block is refused, with the reason shown, when the address or network:

What only discovery or a single host says - "looks like a DNS server (port 53 open)", "looks like a gateway", a gateway one host reports, a host that says it is a domain controller - is shown as a warning in the preview and in the approval text, never a refusal: anyone can open a port and a compromised host can report anything, so these must neither shield an attacker nor stop blocking.

The block preview lists what is protected and why (Never blocked) and the warnings (Check before blocking). A network counts when it overlaps: 10.0.0.0/24 is refused when the server is 10.0.0.5.

Automatic blocks - a decoy's Auto-block source, a playbook step, the Defense console, Under Attack - name a single address only. A network is blocked only by a person, from this page, with four-eyes. A decoy trip that reports anything but a single address blocks nothing; the reported text is kept on the trip.

For Every host, two kinds of host are skipped and listed with the reason: a host on the pinned server or operator never-touch list, and a host whose own address is inside the blocked network. Each agent also refuses, on the host, an address or network that holds its own address, its DNS resolvers, its default gateways or the server as that host reaches it - and refuses every block while it cannot resolve the server's name.

54.2 What the Blocklist page shows#

Path: Blocklist (Investigation group).

Select a row to open the entry. It shows the scope, the source, the reason, who blocked it and who signed, since and until when, and every host with its state:

Host stateMeaning
pendingTo be sent, or sent and not yet confirmed. An offline host waits here ("waiting for the host to come online") and gets the block when it next checks in.
appliedThe host confirmed the block.
failedThe host refused (its reason is shown, for example the firewall tool's error), or it did not answer after five attempts.
removingThe unblock is on its way to the host.
removedThe host confirmed the unblock, or never applied the block.
skippedNever sent: never-touch host, or the host's own address is inside the network.

A command the host received but did not answer is sent again automatically; one that timed out or expired before the host ran it is sent again, up to five attempts.

54.3 Procedure: block an address#

  1. Press Block an address on the Blocklist page, or Block <address> from an alert, a honeypot trip, or a network device (54.6).
  2. Enter the Address or network (203.0.113.7, 203.0.113.0/24, 2001:db8::/48).
  3. Choose Where: This host (only when you came from a host, an alert or a trip) or Every host, including hosts enrolled later.
  4. Choose Expires: 1 hour, 24 hours, 7 days, Permanent, or Until a date and time (at least five minutes and at most a year ahead).
  5. Write Why. The approver reads it.
  6. Read the preview: how many hosts get the block, how many are offline now (they apply it when they come back) and which are skipped and why - or "Not allowed: <reason>" (54.1).
  7. Press Block at this host or Block at every host. With dual control on, the request is sent for approval; the approver reads the address, the scope (an every-host block reads "EVERY host" with the host count) and the expiry. Run it from Approvals once approved.

If the address is already on the blocklist, the preview and the approval name that entry. A request it already covers (same or wider scope, same or later expiry) changes nothing; anything else becomes a separate entry with exactly the scope and expiry you chose. An existing entry is never widened or lengthened by a new block.

54.4 Procedure: unblock#

  1. Open the entry and press Unblock everywhere, then confirm.
  2. An every-host or several-host entry, or one made through Defense or a playbook, needs a second administrator; a one-host entry made here or by a decoy does not.
  3. Every host that may hold the rule is sent the unblock (state removing, then removed): one that confirmed the block, and also one whose block timed out, failed part way or was retried. A host the block never reached is cleared at once, and a block not yet picked up by its host is withdrawn. The agent removes every copy of the rule and then checks that none is left (iptables -C, both Windows Firewall directions, the live pf anchor on macOS). A rule that was already gone is a success. A real failure - the xtables lock held by another program, the firewall service stopped, a rule still in place - keeps the host in removing and the unblock is sent again, up to five times, then failed with the reason. An agent older than 1.5.15.s cannot tell "no rule" from a failure, so its answer is never taken as removed. A block an agent refused before touching its firewall (an older agent and a network) left nothing behind, so that host is cleared at once.
  4. An entry that stays in removing because a host cannot confirm (an older agent, a host gone for good): check those hosts yourself, then Mark removed with what you checked. It needs a second administrator; nothing is sent to the hosts.
  5. When another entry still blocks the same address on a host, that host's rule stays and the host reads "rule kept on the host: entry #N still blocks this address there".

For an entry that applies to several named hosts (not every host), Unblock here on a host unblocks that host only.

An entry made by an Under Attack activation is listed here but rolled back from that activation's war room ("Made by Under Attack activation #N").

An unblock made elsewhere removes every rule for the address on that host. The entry it belongs to (a Defense or playbook block for Defense > Undo, the activation's entry for an Under Attack rollback) shows removed there ("unblocked by another action"); every other entry that still wants the address blocked on that host is re-applied ("re-applied: an unblock from another action ... removed the rule"), so no entry reads applied for a rule that is gone.

A new block of an address whose unblock is still on its way to a host waits for it ("waiting for the earlier unblock (entry #N) to finish on this host") and is sent once that unblock is done.

54.5 Expiry and retry#

54.6 Entry points#

FromButtonPrefilled
Logs > Alerts > alertBlock <address> (one per source address)the address, the alert as the reason
Honeypots > tripBlock <address>the address, this host, the trip as the reason
Network > deviceBlock this addressthe address, the device as the reason

A trip a decoy auto-blocked shows Auto-blocked with See each host and unblock, which opens its blocklist entry.

54.7 Where blocks come from#

SourceScopeExpiry
Console (this page)chosen each timechosen each time
Honeypot Auto-block sourcethe decoy's choice: this host or every host (35.5)the decoy's choice: 1 hour to permanent
Defense > dispatch block_ip, a playbook stepthis hostpermanent (unblock here or undo in Defense)
Under Attackthe host the activation acted onuntil the activation's rollback

Every source goes through the checks in 54.1.

54.8 Sandbox#

On a licence with the sandbox, the sandbox shows example entries in every state: an every-host block from the DMZ decoy with one host waiting and one that refused, a permanent network block, a one-host block from an alert and from a playbook, one unblocked and one expired. Sandbox entries never reach an agent.

54.9 Protected addresses#

Path: Blocklist > Protected addresses. The list shows every protected address with why and how firmly: never blocked, never blocked (can be allowed) (a KDC, a gateway hosts report) or shown only (a warning).

Every change needs Execute containment and a second administrator; the approver reads each address added or removed.