Listen to this Post
Introduction:
SSH remains a prime target for attackers seeking initial access, making continuous monitoring and threat visualization critical for Security Operations Centers (SOCs). By leveraging Splunk to transform raw authentication logs into an interactive threat dashboard, analysts can rapidly identify brute-force attempts, suspicious logins, and attack patterns, turning data into actionable defense intelligence.
Learning Objectives:
- Configure universal forwarders to collect SSH authentication logs from Linux and Windows systems into Splunk.
- Enrich log data with geolocation information and parse key fields for correlation.
- Design, build, and automate a custom Splunk dashboard with panels for real-time SSH threat monitoring and alerting.
You Should Know:
- Setting Up SSH Log Collection from Linux and Windows
Effective monitoring starts with centralized log collection. For Linux, SSH logs are typically in `/var/log/auth.log` (Debian/Ubuntu) or `/var/log/secure` (RHEL/CentOS). Windows systems with OpenSSH server log to the Event Viewer. You must install and configure Splunk universal forwarders on these hosts to send logs to your Splunk indexer.
Step‑by‑step guide explaining what this does and how to use it.
– On Linux: Install the Splunk universal forwarder via package manager. Then, configure inputs to monitor the SSH log file.
Download and install Splunk universal forwarder (example for Debian) wget -O splunkforwarder-9.x.x-xxxx-linux-2.6-amd64.deb https://download.splunk.com/products/universalforwarder/releases/9.x.x/linux/splunkforwarder-9.x.x-xxxx-linux-2.6-amd64.deb sudo dpkg -i splunkforwarder-9.x.x-xxxx-linux-2.6-amd64.deb Edit inputs.conf to monitor auth.log sudo nano /opt/splunkforwarder/etc/system/local/inputs.conf
Add the following stanza:
[monitor:///var/log/auth.log] sourcetype = linux_secure index = ssh_logs
– On Windows: Install the universal forwarder MSI, then use the Splunk Web interface or edit `inputs.conf` to monitor Windows Event Logs for SSH.
Example PowerShell to verify OpenSSH events Get-WinEvent -LogName "OpenSSH/Operational" -MaxEvents 5
In `inputs.conf` on the forwarder:
[WinEventLog://OpenSSH/Operational] index = ssh_logs sourcetype = wineventlog
– Verify Data: On your Splunk search head, run `index=ssh_logs | head 10` to confirm logs are ingested.
- Parsing and Enriching SSH Logs with Geolocation Data
Raw logs lack context; enriching them with geolocation based on source IPs helps pinpoint attack origins. Splunk’s built-in `iplocation` command or the GeoIP add-on can map IPs to country, city, and coordinates.
Step‑by‑step guide explaining what this does and how to use it.
– Install GeoIP Add-on: From Splunkbase, download and install the “Splunk Add-on for Lookup File Editing” and a GeoIP database (e.g., MaxMind GeoLite2).
– Create a Lookup Table: Upload the GeoIP CSV to Splunk and configure a lookup definition.
– Enrich Searches: Use `iplocation` in Splunk Processing Language (SPL) to augment events.
index=ssh_logs sourcetype=linux_secure | iplocation src_ip | table _time, user, src_ip, Country, City, action
– Test Enrichment: Run this search to see failed logins with location:
index=ssh_logs "Failed password" | iplocation src_ip | stats count by src_ip, Country, user | sort - count
3. Building the Core SSH Activity Dashboard Panels
A dashboard should answer key SOC questions: Who is attacking? Who succeeded? From where? Use Splunk’s Dashboard Editor to create panels with SPL searches.
Step‑by‑step guide explaining what this does and how to use it.
– Panel 1: Top Failed Accounts – Identifies brute-force targets.
index=ssh_logs "Failed password" | stats count by user | sort - count
In Dashboard Editor, set visualization as a column chart.
– Panel 2: Top Source IPs with Geolocation – Maps attack origins.
index=ssh_logs "Failed password" | iplocation src_ip | geostats count by src_ip
Use a map visualization.
- Panel 3: Successful Logins Timeline – Tracks valid access.
index=ssh_logs "Accepted password" | timechart count by user
Use a line chart.
- Panel 4: Failed Attempts by User and IP – Spots targeted accounts.
index=ssh_logs "Failed password" | stats count by user, src_ip | sort - count
Use a table.
- Save Dashboard: Name it “SSH Threat Monitor” and set permissions for your SOC team.
4. Implementing Brute-Force Detection Logic and Alerts
Automate threat detection by creating scheduled searches that trigger alerts when failure thresholds are exceeded, indicating potential brute-force attacks.
Step‑by‑step guide explaining what this does and how to use it.
– Define Brute-Force SPL: Detect multiple failures from a single IP or for a user.
index=ssh_logs "Failed password" | bin _time span=5m | stats count by src_ip, _time | where count > 10 | table _time, src_ip, count
– Create Alert: In Splunk, save this search as an alert. Set schedule to run every 5 minutes and trigger when results are greater than 0.
– Configure Alert Action: Send email or Slack notification. Use Splunk’s alert actions setup.
– Mitigation Script: Integrate with blocking tools (e.g., fail2ban on Linux). Example automated response via Splunk’s Adaptive Response:
On Linux, a script to block IPs via iptables sudo iptables -A INPUT -s <OFFENDING_IP> -j DROP
- Correlating SSH Logs with Other Data Sources for Enhanced Visibility
True threat intelligence comes from correlating SSH activity with other logs, such as firewall, endpoint detection, or cloud trails, to identify lateral movement or compromised credentials.
Step‑by‑step guide explaining what this does and how to use it.
– Add Data Sources: Ingest logs from firewalls (e.g., pfSense), EDR tools, or AWS CloudTrail into Splunk with appropriate sourcetypes.
– Correlation Search: Look for SSH successes followed by unusual outbound connections.
index=ssh_logs "Accepted password" | join src_ip [ search index=firewall_logs dest_port=443 | stats count by src_ip ] | table _time, user, src_ip, dest_ip
– Expand Dashboard: Add a panel for correlated events. Use a stats table to display.
– Automate Investigations: Use Splunk’s Incident Review app to create cases from correlated alerts.
What Undercode Say:
- Key Takeaway 1: Building a custom SSH dashboard in Splunk is not just about visualization—it’s a hands-on exercise in understanding attacker behavior and streamlining SOC workflows, from log enrichment to real-time alerting.
- Key Takeaway 2: This approach transforms passive log data into proactive threat intelligence, enabling analysts to quickly identify brute-force patterns, geolocate attacks, and correlate events across sources, which is essential for modern blue-team defense.
Analysis: The project underscores the importance of homelabbing in cybersecurity skill development, bridging theory and practice. By integrating geolocation, automated detection, and cross-source correlation, the dashboard moves beyond basic monitoring to active threat hunting. However, its effectiveness depends on log fidelity and proper tuning to reduce false positives. For SOC teams, such dashboards can reduce mean time to detect (MTTD) for SSH-based incidents, but they must be complemented with robust incident response plans and regular updates to threat logic.
Prediction:
As attackers increasingly automate SSH brute-force attacks and use compromised credentials for lateral movement, AI-driven anomaly detection within Splunk dashboards will become standard. Future iterations will likely integrate machine learning models to baseline normal SSH behavior and flag deviations in real-time, reducing analyst workload. Additionally, with the rise of hybrid cloud environments, SSH monitoring will expand to cloud instances and containers, requiring dashboards to aggregate data across on-prem and multi-cloud infrastructures. This evolution will make custom, intelligent dashboards indispensable for SOCs, turning reactive monitoring into predictive threat prevention.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Raymondyubei Soc – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
