The Active Response Playbook: Automating Threat Mitigation

Detecting threats is only half the battle. The other half is responding fast enough to minimize damage. Active Response in Sentinel Nerd automates your incident response by taking action directly on your UniFi infrastructure when threats are detected.

This guide provides four production-ready playbooks you can implement today, along with critical safety guidelines to prevent automated responses from causing more harm than good.

What Is Active Response?

Active Response is Sentinel Nerd’s automated threat mitigation system. When a detection rule triggers, Active Response can automatically:

• Block a client — Prevent a device from accessing the network
• Quarantine to VLAN — Move a device to an isolated network segment
• Block an external IP — Add an IP to your firewall’s deny list
• Disable an Access credential — Revoke a badge or PIN code
• Rate limit — Throttle traffic from a specific source
• Notify and escalate — Send alerts through PagerDuty, Slack, or webhooks

These actions execute in seconds, far faster than any manual response. The difference between a 3-second automated block and a 30-minute manual investigation can be the difference between a blocked attack and a compromised network.

Safety First

Automated response is powerful and potentially dangerous. A misconfigured playbook can lock out legitimate users, disrupt operations, or create denial-of-service conditions against your own network.

Before implementing any playbook, set up these safety controls:

Allow Lists

Create allow lists for devices and users that should never be auto-blocked:

• Admin workstations — Your own devices
• Critical infrastructure — Domain controllers, DHCP servers, NAS
• Executive devices — Avoid the career-limiting move of auto-blocking the CEO
• Service accounts — Monitoring tools, backup systems
• Known IP ranges — Your office IP range, VPN endpoints

Configure allow lists in Settings > Active Response > Allow Lists.

Dry Run Mode

Every new playbook should start in dry run mode:

1. Enable the playbook with dry_run: true
2. Let it run for at least one week
3. Review the “would have triggered” log in Active Response > Dry Run History
4. Verify that every proposed action is appropriate
5. Only then switch to live mode

Auto-Revert Timers

Set every blocking action to automatically revert after a defined period:

• Brute force blocks: 1-4 hours (attacker moves on, legitimate user can retry)
• IoT quarantine: 24 hours (gives you time to investigate)
• IP blocks: 24-72 hours (threat intelligence may change)

Auto-revert prevents permanent lockouts from false positives. You can always extend a block manually if the threat is confirmed.

Rate Limiting Actions

Limit how many Active Response actions can execute in a given period:

safety:
  max_actions_per_hour: 10
  max_blocks_per_hour: 5
  cooldown_after_action: 60s

This prevents a runaway rule from blocking your entire network in minutes.

Playbook 1: Brute Force Auto-Block

Goal: Automatically block IPs that are attempting brute force attacks against SSH, web admin panels, or other authentication services.

Detection Rule

id: active-response-brute-force
name: Brute Force Auto-Block
description: Blocks external IPs after multiple failed authentication attempts
severity: high
category: credential-attack
enabled: true

conditions:
  - field: event.type
    operator: in
    value: [ssh_login_failed, web_login_failed, vpn_login_failed]
  - field: source.is_external
    operator: equals
    value: true

aggregation:
  group_by: source_ip
  count: 10
  window: 5m

actions:
  - alert
  - active_response:
      action: block_ip
      target: "{{source_ip}}"
      duration: 4h
      reason: "Brute force: {{count}} failed attempts in 5 minutes"

How It Works

1. External IP fails authentication 10 times in 5 minutes
2. Sentinel Nerd adds the IP to your UniFi firewall’s deny list
3. All traffic from that IP is blocked for 4 hours
4. Alert is sent to your configured channels
5. After 4 hours, the block automatically expires

Tuning Tips

• Adjust the threshold based on your environment. 10 in 5 minutes is aggressive. If you have users who frequently fat-finger passwords, raise it to 15-20.
• Add GeoIP filtering — If your legitimate users are all in one country, you can lower the threshold for foreign IPs.
• Exclude VPN IPs — If you use a VPN with a shared exit IP, add it to the allow list.

Playbook 2: IoT Device Quarantine

Goal: Automatically quarantine IoT devices that exhibit suspicious behavior, moving them to an isolated VLAN where they can’t reach internal resources.

Detection Rule

id: active-response-iot-quarantine
name: Suspicious IoT Quarantine
description: Quarantines IoT devices showing signs of compromise
severity: high
category: iot-security
enabled: true

conditions:
  - field: vlan_id
    operator: equals
    value: 40
  - any:
      - field: event.type
        operator: equals
        value: ids_alert
      - conditions:
          - field: event.type
            operator: equals
            value: dns_query
          - field: destination.reputation
            operator: equals
            value: malicious
      - conditions:
          - field: event.type
            operator: equals
            value: traffic_anomaly
          - field: bytes_sent
            operator: greater_than
            value: 1073741824

actions:
  - alert
  - active_response:
      action: quarantine_vlan
      target: "{{client_mac}}"
      quarantine_vlan: 99
      duration: 24h
      reason: "IoT device suspicious activity: {{event.type}}"

Prerequisites

Create a quarantine VLAN (VLAN 99) in your UniFi controller:

• Subnet: 10.0.99.0/24
• No internet access (firewall rule blocking all WAN traffic)
• No access to any other VLAN
• DHCP enabled (so the device gets an IP and you can still identify it)
• Optional: redirect HTTP traffic to a captive portal explaining the quarantine

How It Works

1. An IoT device on VLAN 40 triggers IDS, contacts a malicious domain, or sends anomalous data volumes
2. Sentinel Nerd moves the device to VLAN 99 (quarantine) via the UniFi controller API
3. The device loses all network access except the quarantine VLAN
4. Alert is sent with device details and the reason for quarantine
5. After 24 hours, the device is moved back to VLAN 40 (or you manually extend the quarantine)

Tuning Tips

• Start with dry run — IoT devices have varied traffic patterns. Run dry for 2 weeks to baseline.
• Whitelist smart home hubs — Devices like Home Assistant or SmartThings talk to many cloud services and may trigger false positives.
• Monitor the quarantine VLAN — Quarantined devices may continue trying to beacon to C2 servers, providing valuable threat intelligence.

Playbook 3: After-Hours Access Escalation

Goal: Escalate to PagerDuty when someone accesses a secure area outside business hours, especially if they fail authentication.

Detection Rule

id: active-response-after-hours-escalation
name: After-Hours Secure Area Escalation
description: Escalates after-hours access to secure areas via PagerDuty
severity: critical
category: physical-security
enabled: true

conditions:
  - field: event.source
    operator: equals
    value: unifi_access
  - field: event.type
    operator: in
    value: [door_unlock, door_access_denied]
  - field: door.zone
    operator: in
    value: [server_room, network_closet, executive_suite]
  - field: event.hour
    operator: not_between
    value: [7, 19]

actions:
  - alert
  - active_response:
      action: notify
      channel: pagerduty
      severity: critical
      message: "After-hours access: {{event.type}} at {{door.name}} by {{credential.holder_name}} at {{event.timestamp}}"
  - active_response:
      action: notify
      channel: slack
      target: "#security-critical"
      message: "After-hours access event at {{door.name}}. Check Protect footage."

How It Works

1. Someone badges into (or fails to badge into) a secure area outside 7 AM - 7 PM
2. A critical alert is generated
3. PagerDuty page is sent to the on-call security person
4. Slack message posted to #security-critical with a prompt to check camera footage
5. The responder reviews the alert, checks Protect footage, and decides if action is needed

Enhancement: Auto-Pull Camera Footage

On Enterprise plans, you can configure the playbook to automatically capture a Protect snapshot:

  - active_response:
      action: protect_snapshot
      camera: "{{door.associated_camera}}"
      duration: 60s
      attach_to_alert: true

This captures 60 seconds of footage from the camera associated with the door and attaches it to the alert. The responder can review footage directly in the alert without opening Protect.

Playbook 4: DDoS Rate Limiting

Goal: Automatically rate-limit traffic from sources that are flooding your network, mitigating volumetric attacks.

Detection Rule

id: active-response-ddos-rate-limit
name: DDoS Rate Limiting
description: Rate limits external IPs generating excessive traffic
severity: critical
category: dos-attack
enabled: true

conditions:
  - field: event.type
    operator: equals
    value: traffic_summary
  - field: source.is_external
    operator: equals
    value: true
  - field: packets_per_second
    operator: greater_than
    value: 10000

aggregation:
  group_by: source_ip
  count: 3
  window: 1m

actions:
  - alert
  - active_response:
      action: rate_limit
      target: "{{source_ip}}"
      limit: 1000pps
      duration: 1h
      reason: "DDoS mitigation: {{packets_per_second}} pps sustained"
  - active_response:
      action: block_ip
      target: "{{source_ip}}"
      duration: 1h
      condition: "packets_per_second > 50000"
      reason: "Severe DDoS: blocking at firewall"

How It Works

1. An external IP sends more than 10,000 packets per second for 3+ minutes
2. Sentinel Nerd applies a rate limit of 1,000 pps to that source
3. If the traffic exceeds 50,000 pps, the IP is blocked entirely
4. Critical alert sent to all channels
5. Rate limit/block expires after 1 hour

Tuning Tips

• Know your normal traffic — Baseline your peak legitimate traffic before setting thresholds. A busy web server might legitimately see 5,000+ pps.
• Don’t rate-limit CDN IPs — Add CloudFlare, AWS CloudFront, and similar CDN IP ranges to your allow list.
• Coordinate with your ISP — For truly volumetric DDoS, you need upstream mitigation. This playbook handles application-layer and smaller volumetric attacks.

Monitoring Your Automations

Active Response actions should be monitored like any other critical system:

Review the Action Log

Check Active Response > Action Log regularly for:

• Actions taken (were they appropriate?)
• Actions blocked by allow lists (is the allow list correct?)
• Auto-reverts (did blocked devices resume normal behavior?)
• Failed actions (connection issues with UniFi controller?)

Track False Positive Rate

Measure how often Active Response takes incorrect action:

• Target: Less than 5% false positive rate for blocks
• Target: Less than 1% false positive rate for quarantines
• If you exceed these, tighten conditions or raise thresholds

Set Up Meta-Alerts

Create a detection rule that alerts when Active Response itself is behaving unusually:

id: active-response-meta-alert
name: Active Response Unusual Activity
description: Alerts when Active Response takes more actions than normal
severity: high
category: system-health
enabled: true

conditions:
  - field: event.type
    operator: equals
    value: active_response_action

aggregation:
  count: 20
  window: 1h

actions:
  - alert
  - active_response:
      action: pause_all_responses
      duration: 30m
      reason: "Unusual Active Response volume - pausing for review"

This pauses all automated responses if more than 20 actions fire in an hour, giving you time to investigate whether something has gone wrong.

When NOT to Automate

Not every threat should trigger automated response:

• Internal devices with legitimate business reasons for unusual traffic patterns (backup servers, security scanners)
• Executive or VIP devices — False positive blocks on the wrong person create organizational problems
• Complex attack patterns that require human judgment to assess
• First-time events — If you’ve never seen a pattern before, investigate manually before automating a response
• Anything you’re not confident about — When in doubt, alert and investigate rather than auto-respond

The goal of Active Response is to handle the high-volume, well-understood threats automatically so your team can focus on the complex, novel threats that require human intelligence.

---

Start with Playbook 1 (brute force auto-block) in dry run mode. It’s the safest to automate and provides the most immediate value. Once you’re comfortable with the mechanics, add the other playbooks one at a time.

Active Response doesn’t replace your incident response team. It’s the first responder that buys your team time and handles the obvious threats while they focus on the hard problems.

For more details on Active Response configuration, see our Active Response documentation.