BRB Lockdown Procedures

Owner: Anchor MSP Operations Lead Last reviewed: 2026-05-24

Purpose

Define how BRB lockdowns are triggered, what actions the agent performs during lockdown, how emergency access works, and how forensic evidence is collected and preserved.

Scope

All systems under Anchor managed production with BRB agents deployed and operational.

Triggering a Lockdown

A BRB lockdown can be triggered through two methods:

API Trigger

Send a POST request to the BRB controller API:

curl -X POST https://brb-controller.anchor.internal/api/v1/lockdown \
  -H "Authorization: Bearer $BRB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "system_id": "SYSTEM_ID",
    "reason": "Confirmed ransomware activity detected by Wazuh FIM",
    "triggered_by": "operator.name"
  }'

The API returns a lockdown event ID and confirms the command has been dispatched to the agent.

Dashboard Trigger (Glance)

1. Navigate to the BRB section in the Glance dashboard.
2. Select the target system from the system list.
3. Click the lockdown button (the red button).
4. Enter the lockdown reason in the confirmation dialog.
5. Confirm the lockdown.

Both methods produce identical results. The API method is preferred for automation and scripted responses. The dashboard method is available for operators who need a visual interface during high-stress incidents.

What Happens During Lockdown

When a lockdown command is received, the BRB agent executes four actions in sequence. All four must complete for the lockdown to be considered successful.

1. Network Isolation

The agent applies restrictive firewall rules that block all inbound and outbound traffic except:

• Emergency SSH — Inbound SSH on the configured port from the Anchor management network only.
• Agent-to-controller — Outbound to the BRB controller and Redis for command reception.
• Forensic upload — Outbound to R2 for forensic package upload.

All other traffic is dropped. This prevents an attacker from maintaining command-and-control connections, exfiltrating additional data, or spreading laterally.

2. Service Shutdown

The agent stops all configured services (Docker containers, application processes, database servers, web servers). Services are stopped gracefully with a timeout; if a service does not stop within 30 seconds, it is force-killed.

The emergency SSH service and the BRB agent itself are excluded from shutdown.

3. User Account Locking

All user accounts on the system are locked except the designated emergency SSH user. This prevents an attacker from using compromised credentials to regain access through any remaining entry point.

4. Session Termination

All active sessions (SSH, application, database) are terminated immediately. This forcibly disconnects any active attacker sessions.

Emergency Access

During lockdown, the system is accessible only via:

1. Emergency SSH user — A pre-configured account with SSH key authentication only (no password). This user has sudo access for forensic investigation and manual recovery actions.
2. Access is restricted to connections from the Anchor management network. All other source IPs are blocked by the lockdown firewall rules.
3. Emergency access is logged. All commands executed during the emergency session are captured in the audit trail.

To connect during lockdown:

ssh -i /path/to/emergency_key emergency@SYSTEM_IP

Forensic Package

The BRB agent collects and uploads a forensic package automatically during lockdown.

Collection Contents

Category	Data Collected
System state	Running processes (ps auxf), open files (lsof), mounted filesystems, system uptime, kernel version
Network state	Active connections (ss -tulnp), firewall rules (iptables -L -v -n), routing table, DNS configuration
User state	Logged-in users (who, w), recent logins (last), cron jobs for all users
Logs	System logs, auth logs, application logs (last 24 hours)
File integrity	SHA256 checksums of critical system files and application binaries
Configuration	Contents of /etc/ (sanitized -- credentials removed)

Upload and Verification

1. The forensic data is archived into forensics.tar.gz.
2. A SHA256 checksum file (forensics.tar.gz.sha256) is generated.
3. Both files are uploaded to R2 at the path: s3://brb-forensics/<client_id>/<system_id>/event-<timestamp>/
4. The controller records the upload path and checksum in the event log.

Forensic Integrity

1. The SHA256 checksum enables verification that the forensic package has not been tampered with after collection.
2. R2 bucket access is restricted to the Operations Lead and designated forensic reviewers.
3. Forensic packages are retained for the duration of any related investigation plus 1 year.

Lockdown Verification

After triggering a lockdown, verify it was successful:

1. Check the controller dashboard (Glance): The system status should show "Locked Down" with a timestamp.
2. Check Slack: #anchor-incidents-critical should have a lockdown notification.
3. Verify via emergency SSH:

# Network isolation
iptables -L -v -n                    # Restrictive rules in place
ping 8.8.8.8                         # Should fail (outbound blocked)

# Services stopped
systemctl list-units --type=service  # Only essential services running

# Accounts locked
passwd -S username                   # Should show "L" (locked)

# No active sessions
who                                  # Only emergency user

Failed Lockdown

If a lockdown action fails (e.g., a service cannot be stopped, firewall rules fail to apply):

1. The agent reports the partial failure to the controller.
2. The controller alerts #anchor-incidents-critical with details of which actions failed.
3. The operator must manually complete the failed actions via the emergency SSH session.
4. A partial lockdown is still better than no lockdown. Do not abort the lockdown because one action failed.

Exceptions

None. Lockdown procedures are the same for all BRB-protected systems. System-specific service lists and configuration paths are defined in each system's agent configuration file (/etc/brb/agent.yaml).