Documentation
Docs Home › Security › Brute Force

Brute Force

Brute-force and login alerting

Purpose

Detect repeated authentication failures (ssh, ftp, smtp, http, pop3, imap) and optional login-rate / SSH-login / sudo alerts. Signals come from Agent log monitoring or Hosting collectors. Hosting does not block.

Configuration

Group — do not treat each nested integer as a novel product:

security.brute_force.<service>: enabled, failure_threshold, time_window (seconds), block_duration (seconds), whitelist, notify_on_block, minimum_failures_for_alert.

security.login_rate_limit: enabled, check_interval, time_window, default_threshold, block_on_violation, per-service thresholds.

security.ssh_login_alerts / security.sudo_alerts: enabled, alert_users, alert_on_new_ip / alert_on_root, business hours, whitelist, admin_emails, dedup_window.

Agent log_monitoring.files[]. Hosting hosting.ssh.auth.v1 (and ftp/mail) — observation only; source must not stay permission_blocked.

Custom parsers: /api/v1/log-parsers/custom — not a hosted SIEM.

Operator APIs

  • GET /api/v1/security/login-failures
  • Unblock: POST /api/v1/security/login-failures/:ip/unblock
  • Login-rate stats/check
  • SSH/sudo GET .../status|config|stats, PUT .../config, POST .../check
    POST .../test is not a daily operator cookbook.

Verification

Security logs for brute-force log_type; notifications if enabled. Hosting: collection_status COLLECTING on Hosting status API.

Do not

  • Treat Hosting auth sources as fail2ban replacement enforcement
  • Publish PPS
  • Claim SOC2/ISO/HIPAA