CanaryTokens: Turning SSH Port Exposure into Real‑Time Attack‑Chain Detection

Introduction

In the cloud‑native era, SSH is the most common remote‑management protocol for Linux servers, and exposing port 22 is almost inevitable. Shodan reports over 20 million publicly reachable SSH services worldwide, receiving billions of brute‑force attempts daily. Traditional passive defenses such as password policies and firewall rules are insufficient against APTs and zero‑day exploits.

Technical Background

SSH Attack Landscape and Challenges

SSH attacks have formed a complete supply chain, from automated scanners and password‑dictionary services to botnet rentals. Common techniques include:

Brute‑force attacks : high‑frequency login attempts using weak passwords.

Key‑hijacking attacks : stealing private keys for lateral movement.

Man‑in‑the‑middle attacks : intercepting SSH sessions at the network layer.

Vulnerability exploitation : zero‑day attacks against specific SSH versions.

Traditional defenses suffer from two core problems:

Late detection : intrusions are discovered only after successful compromise.

Difficult forensics : attackers’ origin and subsequent actions are hard to trace.

CanaryToken Principle

CanaryToken, inspired by miners’ use of canaries to detect toxic gases, is an active bait technology. By deploying seemingly legitimate resources that are actually traps, any access immediately triggers an alert.

Key advantages:

Zero false positives : normal operations never touch the bait.

Early warning : alerts appear in the early stages of an attack chain.

Full attack tracing : records the attacker’s complete behavior.

Low operational cost : no complex rule sets or continuous tuning required.

Core Implementation

1. SSH Service Hardening Baseline

Before deploying the tracing system, establish a solid hardening baseline. The following is a production‑grade sshd_config configuration:

# /etc/ssh/sshd_config security hardening
# ============ Network layer ============

# Listen only on internal interface
ListenAddress 10.0.1.100
Port 22

# Protocol version
Protocol 2

# ============ Authentication ============

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

PermitRootLogin no
PermitEmptyPasswords no

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# ============ Session security ============

StrictModes yes
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# ============ Access control ============

AllowUsers [email protected].* [email protected].*
DenyUsers test guest
AllowGroups ssh-users

# ============ Feature restrictions ============

X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
PermitUserEnvironment no

# ============ Logging ============

LogLevel VERBOSE
SyslogFacility AUTH

# ============ Ciphers ============

Ciphers [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256

# Disable weak algorithms
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

An automation script ssh_hardening.sh applies the above configuration, backs up the original file, sets permissions, installs fail2ban, configures auditd, and restarts the SSH service.

#!/bin/bash
# ssh_hardening.sh - SSH service hardening script
...

2. CanaryToken Deployment

The most effective token in an SSH environment is a fake public key placed in authorized_keys with a command wrapper that logs the event and sends an alert:

#!/bin/bash
# deploy_ssh_canary.sh - Deploy SSH CanaryToken
...
cat > /usr/local/bin/ssh_canary_alert.sh <<'ALERT_SCRIPT'
#!/bin/bash
# SSH Canary Token alert script
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
SOURCE_IP=${SSH_CONNECTION%% *}
...
EOF
chmod 755 /usr/local/bin/ssh_canary_alert.sh

Additional filesystem traps (e.g., dummy database credentials, backup scripts) are created and monitored with auditctl. A systemd service ssh-canary-monitor.service watches audit logs for token triggers and forwards alerts via webhook, email, or syslog.

3. Attack‑Chain Tracing and Analysis

A set of Bash tools parses authentication logs, aggregates failed and successful login attempts, performs geographic IP lookup, and generates a comprehensive report. The main analyzer ssh_attack_analyzer.sh produces sections such as failed attempts, successful logins, time‑of‑day anomalies, geographic distribution, attack patterns, CanaryToken triggers, threat intelligence, system integrity checks, and remediation recommendations.

#!/bin/bash
# ssh_attack_analyzer.sh - SSH attack chain analysis tool
...

A complementary script ssh_auto_response.sh records attacks in an SQLite database, decides whether to ban an IP based on a configurable threshold, and automatically applies iptables or fail2ban bans, while sending alerts to multiple channels.

#!/bin/bash
# ssh_auto_response.sh - SSH attack automatic response system
...

4. Practical Cases

Case 1: Large Internet Company – 5 000+ Linux servers, >10 million daily brute‑force attempts. After deploying the hardening baseline, fail‑2‑ban, and CanaryToken matrix, mean intrusion detection time dropped from 72 hours to 12 minutes, 15 APT attack chains were fully traced, and over 500 000 malicious IPs were automatically blocked.

Case 2: Financial Industry Compliance – Required Tier‑3 and PCI‑DSS audit trails. Implemented forced‑command session recording, encrypted log archiving, and compliance‑check scripts that verify password policies, auditd configuration, key permissions, and session timeouts.

Best Practices

Layered defense: network‑level iptables rules, hardened SSH config, comprehensive auditing.

CanaryToken deployment principles: realism, attractiveness, stealth, diversity, and periodic rotation.

Alert‑response workflow: critical alerts trigger immediate IP bans and ticket creation; high alerts trigger short‑term monitoring; medium alerts generate email notifications.

Regular security drills: simulate token triggers, verify fail2ban status, and test monitoring pipelines.

Conclusion and Outlook

SSH port exposure is unavoidable, but a systematic security architecture that combines hardening, active CanaryToken baiting, automated detection, and rapid response can reduce risk to an acceptable level. While CanaryTokens are not a silver bullet, they are a crucial component of a broader defense‑in‑depth strategy that integrates threat intelligence, zero‑trust principles, cloud‑native considerations, and continuous improvement.