Your SSH logs contain far more intelligence than individual failed login attempts. Sophisticated attackers coordinate across multiple geographic locations, creating attack patterns that reveal their intentions 20-30 minutes before they escalate to credential compromise attempts.
Most sysadmins focus on blocking individual IPs after failed attempts. This reactive approach misses the bigger picture: coordinated infrastructure attacks that probe multiple servers simultaneously from different countries, testing the same usernames within tight time windows.
Why Geographic Attack Patterns Matter More Than Individual Failed Logins
Traditional SSH monitoring treats each failed login as an isolated incident. Block the IP, move on. But modern infrastructure attacks operate differently.
Attackers use compromised systems across multiple countries to probe your infrastructure simultaneously. They're not trying random passwords - they're mapping your systems, identifying valid usernames, and coordinating timing to avoid detection thresholds.
The Anatomy of Coordinated Infrastructure Attacks
A typical coordinated attack follows this pattern:
- Reconnaissance phase: Light probing from 3-5 different countries within a 10-minute window
- Username enumeration: Testing common accounts (admin, root, service names) across locations
- Timing coordination: Attacks spaced to stay below individual IP blocking thresholds
- Escalation preparation: Building a target list before launching credential attacks
By the time attackers move to serious credential attempts, they already know which usernames exist, which services are running, and which servers respond fastest.
What Your SSH Logs Actually Tell You About Attack Coordination
Your SSH authentication logs contain the raw data needed to detect these patterns. The key fields that matter:
- Timestamp precision: Attacks coordinated within 10-15 minute windows
- Source IP geolocation: Multiple countries attempting identical usernames
- Username patterns: Same account names across different geographic sources
- Service enumeration: SSH version probing that indicates reconnaissance
For deeper technical detail on log parsing and field extraction, see our Building Linux Intrusion Detection with auditd and Bash guide.
Parsing SSH Logs for Geographic Intelligence
Building geographic attack detection requires extracting the right information from your SSH logs and correlating it across time and location.
Essential Log Fields for Attack Pattern Recognition
Step 1: Identify your SSH log location
Most systems store SSH authentication attempts in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS). Verify your location:
ls -la /var/log/auth.log /var/log/secureStep 2: Extract core attack data
Focus on these log elements for pattern recognition:
- Failed password attempts with source IP
- Invalid username attempts (reconnaissance)
- Successful authentications from unexpected locations
- SSH version string requests (service enumeration)
Step 3: Build geographic correlation
Use a geographic IP database (MaxMind GeoLite2 is free) to map attack sources to countries. The pattern you're looking for: multiple countries attempting identical usernames within short time windows.
Building Your Geographic Clustering Script
Step 4: Create time-windowed analysis
Group authentication attempts into 15-minute windows. Track which countries attempt which usernames in each window.
Step 5: Define clustering thresholds
Set detection rules:
- 3+ different countries attempting the same username within 15 minutes
- Geographic spread covering 2+ continents
- Username enumeration across multiple accounts
Step 6: Build correlation logic
Track patterns across your entire infrastructure, not individual servers. Coordinated attacks often probe multiple systems simultaneously.
Creating Automated Early Warning Triggers
Once you're collecting geographic attack data, build automated alerts that fire before attackers escalate to serious credential attempts.
Setting Threshold Rules That Minimise False Positives
Step 7: Implement graduated alert levels
- Yellow alert: Same username from 2 countries within 10 minutes
- Orange alert: Same username from 3+ countries within 15 minutes
- Red alert: Username enumeration across multiple accounts from coordinated locations
Step 8: Add infrastructure-wide correlation
Don't alert on individual server patterns. Wait for coordination across multiple systems in your infrastructure.
Step 9: Build time-based escalation
If initial geographic clustering continues for 20+ minutes without escalation to credential attacks, raise alert priority. Attackers are likely building comprehensive target intelligence.
Integrating Geographic Detection with Your Existing Monitoring
Step 10: Connect to your alert infrastructure
Send geographic attack warnings through your existing notification channels. Many teams integrate this with Server Scout's alert system to correlate SSH attack patterns with infrastructure performance data.
Step 11: Create response workflows
Define what happens when geographic clustering is detected:
- Temporarily tighten SSH access policies
- Alert security team for manual review
- Increase logging verbosity for affected systems
- Prepare incident response procedures
Testing and Refining Your Detection System
Build confidence in your geographic detection system before relying on it for security decisions.
Simulating Attack Scenarios for System Validation
Step 12: Create controlled test attacks
Use VPN services or cloud instances in different countries to simulate coordinated attacks against test accounts. Verify your detection system identifies the patterns correctly.
Step 13: Tune false positive thresholds
Monitor legitimate authentication patterns from your team. Adjust geographic clustering rules to avoid alerts when team members work from different locations.
Step 14: Build comprehensive monitoring integration
For teams managing large infrastructures, consider integrating geographic attack detection with broader monitoring systems. Our Building Monitoring System Redundancy guide covers multi-region alert architectures.
Step 15: Document and maintain
Keep records of detected attack patterns and response effectiveness. Update geographic databases regularly (IP to country mappings change).
Geographic attack pattern recognition transforms reactive SSH security into predictive infrastructure protection. Instead of blocking IPs after attacks begin, you identify coordination patterns that provide 20-30 minutes of warning before serious credential compromise attempts.
The investment in building these detection systems pays dividends when attackers escalate from reconnaissance to active credential attacks - you'll have comprehensive advance warning and response time that traditional IP blocking never provides.
FAQ
How accurate are geographic IP databases for attack detection?
Free databases like MaxMind GeoLite2 are 95%+ accurate for country-level detection, which is sufficient for identifying coordinated attacks. Perfect precision isn't required - you're looking for patterns across multiple countries, not pinpoint locations.
Will VPN usage by attackers defeat geographic clustering detection?
Sophisticated attackers do use VPNs, but coordinated attacks still create detectable patterns. Even with VPNs, attackers struggle to perfectly randomise timing, usernames, and attack vectors across multiple systems simultaneously.
How do I prevent false alerts when legitimate users travel or work remotely?
Build whitelists for known user accounts and implement graduated alerting. Focus detection on system accounts (root, admin, service accounts) rather than personal user accounts, and require multiple coordinated indicators before alerting.