Blocking Mode

​

Detection vs Blocking

GARNET_BLOCKING=false

​

Enable Blocking

​

GitHub Actions

- uses: garnetlabs/garnet-action@v1
  with:
    blocking-enabled: true
    blocking-mode: strict
  env:
    GARNET_API_TOKEN: ${{ secrets.GARNET_API_TOKEN }}

​

Kubernetes

helm upgrade jibril garnet/jibril \
  --set blocking.enabled=true \
  --set blocking.mode=strict \
  --namespace garnet-system

​

Docker

docker run -d \
  --name jibril \
  --privileged \
  --pid=host \
  -e GARNET_API_TOKEN=$GARNET_API_TOKEN \
  -e GARNET_BLOCKING=true \
  -e GARNET_BLOCKING_MODE=strict \
  ghcr.io/garnetlabs/jibril:latest

​

Blocking Modes

​

Strict Mode

• Blocks all detected threats immediately
• Zero tolerance for suspicious activity
• May cause false positive disruptions
• Recommended for: High-security environments

GARNET_BLOCKING_MODE=strict

​

Permissive Mode

• Blocks only high-confidence threats
• Allows some suspicious activity
• Reduces false positive impact
• Recommended for: Most production environments

GARNET_BLOCKING_MODE=permissive

​

Custom Mode

• Block specific threat types only
• Custom severity thresholds
• Environment-specific policies
• Recommended for: Complex environments

GARNET_BLOCKING_MODE=custom
GARNET_BLOCK_SEVERITY=high,critical

​

What Gets Blocked

​

Blocking Actions

​

Process Termination

1. Immediate termination - Process killed via SIGKILL
2. Parent process tracking - Related processes identified
3. Resource cleanup - Memory and file handles released
4. Event logging - Full forensic details recorded

{
  "action": "process_killed",
  "process": {
    "pid": 12345,
    "command": "xmrig --donate-level=0",
    "user": "app",
    "signal": "SIGKILL"
  },
  "timestamp": "2024-01-15T10:30:00Z"
}

​

Network Connection Blocking

1. Connection termination - Active connections dropped
2. IP/domain blocking - Future connections prevented
3. Firewall rules - Dynamic rules created
4. DNS blocking - Domain resolution blocked

{
  "action": "connection_blocked",
  "network": {
    "destination": "malicious.example.com",
    "ip": "192.168.1.100",
    "port": 8080,
    "protocol": "TCP"
  },
  "block_duration": "24h"
}

​

File System Protection

1. File quarantine - Malicious files isolated
2. Access prevention - File permissions revoked
3. Hash blacklisting - Similar files blocked
4. Backup restoration - Clean versions restored

{
  "action": "file_quarantined",
  "file": {
    "path": "/tmp/malware.exe",
    "sha256": "abc123...",
    "quarantine_location": "/opt/garnet/quarantine/"
  }
}

​

Blocking Policies

​

Default Policies

• Crypto miners - Always blocked
• Known malware - Always blocked
• C2 communications - Always blocked
• Container breakouts - Always blocked

​

Custom Policies

# Block by threat severity
policies:
  - name: "critical-threats"
    action: "block"
    severity: ["critical"]
    
  - name: "high-threats"
    action: "block"
    severity: ["high"]
    environments: ["production"]

​

Allowlist Rules

allowlist:
  - name: "dev-tools"
    pattern: "npm install|yarn install|pip install"
    environments: ["development", "ci"]
    
  - name: "monitoring"
    pattern: "prometheus|grafana|datadog"
    scope: "global"
    
  - name: "internal-traffic"
    network: "10.0.0.0/8"
    action: "allow"

​

Monitoring Blocking Activity

​

Real-Time Dashboard

• Threats Blocked - Number of threats stopped
• Block Success Rate - Percentage of threats caught
• Response Time - Time from detection to block
• False Positive Rate - Legitimate activities blocked

​

Blocking Analytics

• Daily Block Volume - Threats blocked per day
• Threat Type Distribution - Most common threats
• Source Analysis - Where threats originate
• Target Analysis - Most attacked assets

​

Performance Impact

• CPU Usage - Additional processing load
• Memory Usage - Blocking subsystem memory
• Latency Impact - Application performance
• Network Overhead - Blocking traffic costs

​

Handling Blocked Events

​

Immediate Response

1. Automatic notification - Instant alerts sent
2. Incident creation - Tracking ticket opened
3. Forensic preservation - Evidence collected
4. Stakeholder notification - Teams informed

​

Investigation Process

1. Review block details - What was blocked and why
2. Analyze threat context - How did it get there
3. Check for related activity - Broader compromise
4. Verify block effectiveness - Threat actually stopped

​

False Positive Handling

1. Immediate unblock - Restore service quickly
2. Create allowlist rule - Prevent future blocks
3. Notify affected users - Explain disruption
4. Tune detection rules - Reduce false positives

​

Troubleshooting

# Check agent configuration
docker exec jibril printenv | grep BLOCKING

# Ensure privileged mode (Docker)
docker inspect jibril | grep Privileged
# Should show "Privileged": true

# Check if threat type is configured to block
Dashboard → Settings → Blocking Policies

docker exec jibril /opt/jibril/bin/jibril --version
# Needs version 2.0+ for full blocking support

GARNET_BLOCKING_MODE=permissive

allowlist:
  - name: "legitimate-tools"
    pattern: "kubectl|docker|npm"
    environments: ["development"]

GARNET_BLOCK_SEVERITY=critical

GARNET_BLOCKING_MODE=lightweight

GARNET_BLOCK_NETWORKS_ONLY=true

GARNET_BLOCK_CONFIDENCE_THRESHOLD=0.9

# Review block action logs
Dashboard → Events → Filter by "blocked"

# May be coming from different process/location
# Check process hierarchy and file paths

# Block by hash, network, or pattern
# Not just specific process instance

​

Best Practices

​

Deployment Strategy

1. Start with monitoring - Observe before blocking
2. Test in staging - Validate policies work correctly
3. Gradual rollout - Enable blocking incrementally
4. Monitor closely - Watch for false positives

​

Policy Management

1. Document policies - Clear rationale for each rule
2. Regular review - Update policies quarterly
3. Environment alignment - Match policies to risk tolerance
4. Version control - Track policy changes

​

Incident Response

1. Automated escalation - Route critical blocks immediately
2. Investigation playbooks - Standard response procedures
3. Communication plans - Stakeholder notification
4. Post-incident review - Learn from each event

​

Operational Excellence

1. Performance monitoring - Track blocking overhead
2. Accuracy tracking - Measure false positive rates
3. Threat intelligence - Update detection rules regularly
4. Team training - Ensure staff understand blocking

​

Next Steps