Rule Engine Guard & Security Monitoring

SSH abuse observations, Fail2Ban integration, incident history, timed blocks, IP reputation and Guard configuration.

Rule Engine Guard provides an operational view of SSH authentication failures, selected high-connection indicators, IP blocking decisions and history. Its network observations complement the host IDS scanner; they do not replace it. The October 6 source integrates journalctl monitoring, optional automatic mitigation, Fail2Ban and AbuseIPDB lookups.

Investigate before blocking

Start by looking at SSH events and existing restrictions. An event count can include repeated attempts from legitimate clients, proxies or shared NAT egress. Row IDs are derived from the displayed view; verify the actual IP address each time before taking action.

one-click engine 'audit'
one-click engine 'audit ssh'
one-click engine 'audit banlist'
one-click engine 'audit history'

The combined ban list can include One-Click Guard history and Fail2Ban’s SSH jail. Historical bans may already have expired or been manually removed, so distinguish current firewall state from an audit record.

Timed blocks and reversal

From an SSH audit result, the ID selects an observed address. Guard’s parser accepts a duration in seconds, not minutes; the earlier command reference was incorrect. The historical implementation defaults to 3600 seconds (one hour). The permanent option is represented internally by a long timer rather than a timeless firewall policy.

one-click engine 'audit drop 3 dur=300'
one-click engine 'audit unblock 3'

Replace the example ID with a verified current row. Before altering a block, confirm the host’s firewall backend and that a corresponding rule exists. Never assume an ID will continue to identify the same source after event history changes.

Passive and automatic mitigation

The original Guard maintains auto_mitigate in /etc/one-click/rule-engine/guard/guard.conf. Passive mode records events; automatic mitigation may insert temporary firewall blocks when its monitor recognises a relevant event. Review implementation and potential false positives on your installed version before enabling it. Do not enable automatic blocking without a console or out-of-band recovery path.

Fail2Ban jail configuration

Guard can generate a Fail2Ban jail with a chosen name, service port and retry count. This changes Fail2Ban configuration and may restart the service; review the generated jail, log location and action backend first. Its older template uses an sshd filter and iptables-style action, which may require adaptation for hosts using firewalld or nftables.

one-click engine 'audit jail sshd port 22 retry 5'
sudo fail2ban-client status sshd

Review /etc/fail2ban/jail.local and the action file before any production reload. Fail2Ban and One-Click Guard can both block an address; understand which owner is responsible for removing each rule.

AbuseIPDB reputation context

Guard can look up public reputation information for an IP address using an AbuseIPDB API key. A reputation score is investigative context, not proof of malicious intent. The historical CLI accepts a key inline, but this risks exposing it through terminal history or process logs; use a secure approved administrative workflow and protect the key file.

one-click engine 'audit lookup 198.51.100.7'

Key storage: /etc/one-click/rule-engine/guard/abuseipdb.key. Check its filesystem permissions and whether external reports are enabled before using the integration.

State, logs and investigation trail

The original implementation writes Guard state beneath /etc/one-click/rule-engine/guard/: ssh for SSH observations, ddos for selected connection signals, history for block/unblock records, guard.conf for mitigation settings, and last_audit for display timestamps. These logs need normal retention and access control; inspect them rather than treating a colourful status indicator as the source of truth.

Known scope and limits

The original SSH monitor watches authentication failures in systemd journal entries. The connection-rate monitor uses ss heuristics; it is not full packet analysis, a distributed denial-of-service mitigation service or a substitute for upstream network controls. IPv6 handling, restart persistence, log rotation and backend-specific removals should be validated on the deployed version.