Agent skill

attack-response

Emergency playbook for responding to active attacks using INFYNON firewall. Use when the user is under attack, seeing suspicious traffic, experiencing DDoS, noticing brute-force attempts, or investigating blocked requests. Covers immediate IP blocking, log analysis, rule creation, and post-incident hardening.

View SKILL.md on GitHub Repository
Stars 5
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/d4rkNinja/code-guardian/tree/main/infynon-firewall/skills/attack-response

SKILL.md

INFYNON Attack Response Playbook

You are helping the user respond to an active security incident using INFYNON firewall (infynon).

Step 1 — Triage: Understand What's Happening

bash
# See recent blocked requests (last hour)
infynon logs --verdict block --since 1h

# See live traffic stream
infynon logs --follow

# Check top attacking IPs
infynon monitor     # TUI view 6 (Stats) shows top IPs with block counts

In TUI:

  • Press 3 — Blocked view (see what's being blocked and why)
  • Press 4 — IP Inspector (search for specific IP, see per-IP stats)
  • Press 6 — Stats (top blocked paths, top IPs, verdict breakdown)

Step 2 — Immediate Containment

Block a specific IP

bash
infynon block 10.0.0.1
infynon block 192.168.1.100

# Verify it's blocked
infynon logs --ip 10.0.0.1 --since 5m

In TUI: Press 4 (IP Inspector), search for the IP, press b to block.

Block a CIDR range (entire subnet)

Add to infynon.toml under [ip_filter]:

toml
[ip_filter]
blocked_ips = ["10.0.0.0/24", "203.0.113.0/24"]

Config hot-reloads within 2 seconds — no restart needed.

Enable maintenance mode (block ALL traffic immediately)

bash
# In TUI: press m to toggle
# In config: set maintenance_mode = true in infynon.toml

Use maintenance mode when:

  • You're under a heavy DDoS and need to stop all traffic instantly
  • You need to patch a critical vulnerability right now
  • Returns 503 to all requests until you toggle it off

Step 3 — Identify the Attack Type

Brute-force / Credential stuffing

Signs: Many POST requests to /auth/login from same or rotating IPs

bash
infynon logs --verdict block --since 1h | grep "login"

Response:

toml
[rate_limit]
per_ip_per_second = 2        # Tighten rate limit
per_path_per_second = 10     # Path-level limit

[[rules]]
name = "block-login-burst"
priority = 1
action = "RateLimit"
conditions = [
  { type = "PathExact", value = "/auth/login" },
  { type = "Method", value = "POST" }
]

SQL injection scan

Signs: WAF blocking requests with SQLi patterns, high block rate from few IPs

bash
infynon logs --verdict block --since 1h | grep "sqli\|SQLi\|sql"

Response: WAF handles this automatically. Check WAF is enabled:

toml
[waf]
enabled = true    # Ensure this is true

Block the attacker's IP:

bash
infynon block <attacker-ip>

Path traversal / Scanner

Signs: Requests for /.env, /wp-login, /.git, /phpMyAdmin, etc.

bash
infynon logs --verdict block --since 1h | grep "\.env\|wp-login\|\.git"

Response: These are blocked by default WAF. Add specific scanner signatures:

toml
[[rules]]
name = "block-scanners"
priority = 1
action = "Block"
conditions = [
  { type = "UserAgent", pattern = ".*sqlmap.*|.*nikto.*|.*nmap.*|.*masscan.*" }
]

DDoS / High-volume flood

Signs: Thousands of requests per second, server slowdown Response:

toml
[rate_limit]
requests_per_second = 50        # Lower global limit
per_ip_per_second = 5           # Aggressive per-IP limit
per_path_per_second = 20

Then set auto-ban to trigger fast:

toml
[ip_filter]
auto_ban_threshold = 10         # Auto-block after 10 blocked requests (was 50)

XSS injection attempts

Signs: WAF blocking requests with <script>, javascript:, onerror= patterns WAF handles this automatically (12 XSS patterns compiled in). If seeing a new XSS pattern:

toml
[[rules]]
name = "custom-xss"
priority = 2
action = "Block"
conditions = [
  { type = "Body", pattern = ".*document\\.cookie.*" }
]

Step 4 — Post-Incident Hardening

After the immediate incident is contained, harden the config:

Tighten rate limits

toml
[rate_limit]
requests_per_second = 100       # Global baseline
per_ip_per_second = 10          # Per-IP (lower for sensitive endpoints)
per_path_per_second = 50        # Per-path

Add targeted custom rules for observed attack patterns

toml
# Block specific IP ranges known for attacks
[ip_filter]
blocked_ips = ["185.220.101.0/24"]   # Known Tor exit nodes example

# Block common attack user agents
[[rules]]
name = "block-attack-uas"
priority = 1
action = "Block"
conditions = [
  { type = "UserAgent", pattern = ".*curl/.*|.*python-requests.*|.*Go-http.*" }
]

# Require JSON content-type for API routes (prevents form-encoded attacks)
[[rules]]
name = "api-json-only"
priority = 3
action = "Block"
conditions = [
  { type = "PathPrefix", value = "/api" },
  { type = "Method", value = "POST" },
  { type = "ContentType", pattern = "^(?!application/json).*" }
]

Set up email alerts for future incidents

toml
[email]
enabled = true
smtp_host = "smtp.gmail.com"
smtp_port = 587
smtp_user = "you@gmail.com"
smtp_pass = "app-password"
from = "firewall@yourdomain.com"
to = ["admin@yourdomain.com"]
block_threshold = 50        # Alert after 50 blocks in a window

Log Analysis Commands

bash
# All blocks in the last hour
infynon logs --verdict block --since 1h

# All blocks from a specific IP
infynon logs --ip 10.0.0.1

# Filter to specific time windows
infynon logs --verdict block --since 30m
infynon logs --verdict block --since 24h

# Stream live (watch attack in real-time)
infynon logs --follow

# Check specific verdict types
infynon logs --verdict allow    # Normal traffic
infynon logs --verdict block    # Blocked requests
infynon logs --verdict ratelimited  # Rate-limited requests

Logs are written to access.jsonl and blocked.jsonl in the working directory. Parse with jq:

bash
cat blocked.jsonl | jq '. | {ip: .source_ip, path: .path, reason: .reason, time: .timestamp}'
cat blocked.jsonl | jq -r '.source_ip' | sort | uniq -c | sort -rn | head -20

After the Incident

  1. Review your block logs for attack patterns you didn't anticipate
  2. Update custom rules to catch similar attacks automatically next time
  3. Lower auto_ban_threshold if the attacker was active for a long time before being blocked
  4. Consider adding email alerts if you didn't have them — block_threshold = 50 is a good start
  5. Run INFYNON package scan — attackers who probe your API may also target your dependencies:
    bash
    infynon pkg scan

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

d4rkNinja/code-guardian

rule-writer

Help users write custom WAF rules for INFYNON firewall. Use when the user wants to create custom rules, block specific patterns, allow specific IPs, flag suspicious requests, rate-limit specific routes, or tune the firewall beyond default settings. Also use when the user shows you traffic logs and asks what rules to write.

5 0
Explore
d4rkNinja/code-guardian

firewall-setup

Help users set up and manage the INFYNON network firewall — a reverse proxy WAF with TUI dashboard. Use when the user asks about firewall configuration, WAF rules, rate limiting, IP blocking, network security, reverse proxy setup, DDoS protection, or traffic monitoring. Also use when you see infynon.toml in the project.

5 0
Explore
d4rkNinja/code-guardian

package-security

Help users secure their project dependencies using INFYNON CLI. Use when the user asks about package vulnerabilities, CVE scanning, dependency auditing, secure package installation, fixing vulnerable packages, migrating package managers, or monitoring dependencies. Also use when you detect lock files (package-lock.json, yarn.lock, Cargo.lock, uv.lock, poetry.lock, go.sum, Gemfile.lock, composer.lock, etc.) in the project.

5 0
Explore
d4rkNinja/code-guardian

cve-triage

Help users triage and prioritize CVE findings from INFYNON package scans. Use when the user has CVE scan results and needs to decide what to fix, what to defer, or how to handle a specific vulnerability. Covers severity interpretation, fix strategies, safe version selection, and handling false positives.

5 0
Explore
d4rkNinja/code-guardian

eagle-eye-monitor

Help users set up and manage INFYNON Eagle Eye — continuous CVE monitoring with scheduled email alerts. Use when the user wants to monitor projects for new vulnerabilities over time, set up automated CVE alerts, configure SMTP for email notifications, or manage ongoing security monitoring.

5 0
Explore
d4rkNinja/code-guardian

weave

Help users build, run, and analyze API test flows with INFYNON Weave (`infynon weave`). Use when the user asks about API testing, integration testing, flow-based testing, testing API sequences, security probing endpoints, runtime inputs (OTP, 2FA, CAPTCHA), or when .infynon/api/ directory is detected. Covers node creation, flow building, prompt inputs, body editing, AI-assisted wiring, security probes, and TUI visualization. Always use this skill whenever the user mentions testing APIs, flows, weave, integration tests, OTP handling, or prompt inputs — even if they don't say "infynon weave" explicitly.

5 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results