I observed a spike in unauthorized access attempts on a public-facing jump box located in a Mumbai data center. Within 12 minutes of the instance going live, the /var/log/auth.log file was already being flooded with "Failed password" entries from over 40 unique IP addresses. This is the reality of managing internet-exposed SSH services. Without a centralized Security Information and Event Management (SIEM) strategy, these logs are just dead data taking up disk space.

What is SSH Log Analysis?

SSH log analysis is the process of parsing, inspecting, and correlating the records generated by the OpenSSH daemon (sshd). These logs provide a forensic trail of every connection attempt, authentication success, and session termination. In a standalone environment, we use tools like grep or journalctl. In an enterprise environment, we ingest this data into a SIEM to identify patterns that a single log entry cannot reveal.

For security researchers, SSH logs are the primary telemetry source for identifying Brute-Force (T1110) and Password Spraying (T1110.003) attacks. We look for high-frequency failures followed by a single successful login, which often indicates a compromised account.

The Role of SIEM in Centralized Security Monitoring

A SIEM platform like Elastic Stack (ELK), Splunk, or Wazuh acts as a central repository for logs from hundreds of distributed servers. Instead of manually managing individual connections, many modern DevOps teams are adopting secure SSH access for teams to centralize control and visibility. This centralization allows us to correlate SSH failures on a web server with suspicious outbound traffic on a database server—a classic sign of lateral movement.

In the Indian context, organizations under the DPDP Act 2023 must maintain robust logging to demonstrate "reasonable security practices" aligned with the OWASP Top 10. A SIEM provides the audit trail necessary to prove that unauthorized access was detected and mitigated within the timelines prescribed by CERT-In.

Why SSH Logs are High-Value Targets for Security Teams

SSH is the "keys to the kingdom." If an attacker gains SSH access, they gain a shell. From there, they can escalate privileges, install rootkits, or pivot further into the internal network. We monitor SSH logs because they are the first line of defense. A successful login from an unexpected IP, such as a residential ISP in a region where you have no employees, is a high-fidelity indicator of compromise (IoC).

Common SSH Log Files: /var/log/auth.log vs. /var/log/secure

The location of SSH logs depends on the Linux distribution. Debian-based systems (Ubuntu, Kali, Mint) use /var/log/auth.log. RHEL-based systems (CentOS, Rocky, Fedora, Amazon Linux) use /var/log/secure. If the system uses systemd, we can also query the logs directly from the journal.

Querying the last hour of SSH logs on a systemd-based host
journalctl -u ssh --since "1 hour ago" | grep -oE '[0-9]{1,3}(\.[0-9]{1,3}){3}' | sort | uniq -c

Key Components of an SSH Log Entry

A standard SSH log entry contains several critical fields: the timestamp, the hostname, the process ID (PID), the event description, the target username, the source IP address, and the source port. Understanding this structure is essential for writing regex patterns in your SIEM's ingestion pipeline.

Typical failed login entry
Oct 25 14:22:01 web-prod-01 sshd[14502]: Failed password for root from 192.168.1.50 port 54322 ssh2

Identifying Successful vs. Failed Authentication Attempts

We differentiate between "Failed password" and "Accepted password." However, a more subtle indicator is "Invalid user." This occurs when an attacker attempts to log in with a username that does not exist on the system (e.g., admin, ubnt, guest).

Identifying the top 10 IP addresses targeting non-existent users
grep "Invalid user" /var/log/auth.log | awk '{print $(NF-2)}' | sort | uniq -c | sort -nr | head -n 10

Log Collection Methods: Syslog, Forwarders, and Agents

To get logs into a SIEM, we generally avoid manual SCP transfers. The most common method is using a lightweight agent. Filebeat is a popular choice for the Elastic Stack. It monitors the log file and sends new entries to Logstash or Elasticsearch in real-time.

filebeat.yml configuration for SSH logs
filebeat.inputs:

type: log

enabled: true   paths:     - /var/log/auth.log     - /var/log/secure   processors:     - add_host_metadata: ~     - add_cloud_metadata: ~ output.elasticsearch:   hosts: ["https://siem-collector.internal:9200"]   username: "filebeat_internal"   password: "${ES_PWD}"

Parsing and Normalizing SSH Data for Searchability

Raw logs are difficult to query. We need to normalize them into a schema like the Elastic Common Schema (ECS). This involves using Grok patterns or Dissect filters in Logstash to break the string into fields like source.ip, user.name, and event.outcome.

Example Grok pattern for SSH failures
SSH_FAILURE %{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} sshd\[%{POSINT:pid}\]: Failed password for %{USER:user} from %{IP:src_ip} port %{POSINT:port} ssh2

Mapping SSH Events to the MITRE ATT&CK Framework

When an SSH log shows a successful login followed immediately by a sudo command, we map this to Privilege Escalation (TA0004). If we see multiple failed logins followed by one success, it is Brute Force (T1110). Mapping these events helps security teams communicate the severity of an incident to management using a standardized vocabulary.

Detecting Brute Force and Password Spraying Attacks

Brute force attacks are noisy. We look for a high volume of "Failed password" entries from a single IP address within a short window. Password spraying is more tactical; the attacker tries one common password (like Password123) against hundreds of different usernames to avoid account lockout policies.

CLI-based detection for brute force: 10+ failures from one IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | awk '$1 > 10'

Monitoring for Unauthorized Key-Based Authentication

Key-based authentication is more secure than passwords, but it is not infallible. If an attacker steals a private key, the logs will show "Accepted publickey." We must monitor for new keys being added to ~/.ssh/authorized_keys files, which often indicates persistence (T1098).

Tracking Lateral Movement via SSH Pivoting

In a compromised environment, attackers use the "Jump Host" to move deeper. We look for "Accepted password" or "Accepted publickey" entries where the source IP is another internal server. If Web-Srv-01 (10.0.1.5) suddenly initiates an SSH connection to DB-Srv-01 (10.0.2.10), and that is not a standard administrative path, we flag it as lateral movement.

Identifying Anomalous Login Times and Geographic Locations

If your Indian development team only works from 09:00 to 18:00 IST (UTC+5:30), an SSH login at 03:00 IST from an IP registered in Eastern Europe is a massive red flag. SIEMs can use GeoIP databases (like MaxMind) to enrich log data with country and city information.

Setting Thresholds for Failed Login Alerts

Alert fatigue is a real problem. Setting an alert for every failed login will bury your SOC team in noise. Instead, we set thresholds. For example, trigger a "Critical" alert only if there are more than 20 failed attempts from a single IP within 5 minutes, or if there is a successful login from an IP that has never been seen before.

Creating Real-Time Dashboards for SSH Session Activity

A useful SIEM dashboard for SSH should include:

• A heat map of source IPs by country.
• A time-series graph of failed vs. successful logins.
• A list of the "Top Targeted Usernames."
• A table of "Recent Successful Logins" with GeoIP data.

Automating Incident Response with SOAR Playbooks

Security Orchestration, Automation, and Response (SOAR) can take SSH monitoring to the next level. When the SIEM detects a brute-force attack, it can trigger a playbook that automatically adds the offending IP to a blackhole list in the edge firewall or updates the /etc/hosts.deny file on the target server.

Simple automation: Using fail2ban to block IPs
fail2ban-client status sshd
Manually unbanning an IP if it was a false positive
fail2ban-client set sshd unbanip 203.0.113.42

Meeting PCI-DSS, HIPAA, and SOC2 Logging Standards

Compliance frameworks require that logs be immutable and retained for specific periods. PCI-DSS Requirement 10 necessitates the tracking and monitoring of all access to network resources. In India, the DPDP Act 2023 emphasizes the accountability of the Data Fiduciary. If a breach occurs and you cannot provide SSH logs showing how the attacker gained entry, you may face significant penalties (up to ₹250 Crore for certain violations).

Long-term Retention Strategies for SSH Audit Trails

Storing six months of raw SSH logs on high-performance SSDs is expensive. We use a tiered storage approach:

• Hot Tier: Last 30 days of logs available for instant searching in the SIEM.
• Warm Tier: 31-90 days of logs on cheaper storage with slightly slower query times.
• Cold/Archive Tier: 91-180+ days of logs compressed in S3 or Azure Blob storage, only retrieved for forensic audits.

Generating Compliance Reports from SIEM Data

Most SIEMs provide templates for compliance. A "Weekly SSH Access Report" should be scheduled and sent to the CISO. This report should summarize all privileged access and highlight any anomalies that were not resolved by the SOC.

---

Best Practices for Hardening SSH and Improving Log Quality

To make log analysis easier, we should first reduce the noise. Changing the default SSH port from 22 to a random high port (e.g., 2222) will stop 99% of automated script-kiddie scans. This allows the SIEM to focus on more sophisticated, targeted threats.

Reducing Noise: Filtering Known Internal Scanners

Internal vulnerability scanners like Nessus or OpenVAS will generate thousands of "Failed password" logs. We should whitelist these scanner IPs in the SIEM so they don't trigger false positive alerts, though we should still store the logs for audit purposes.

Enabling Verbose Logging for Deeper Forensics

By default, sshd logging is set to INFO. For more detail, change LogLevel to VERBOSE in /etc/ssh/sshd_config. This will include information about the SSH key fingerprints used for authentication, which is invaluable during an investigation.

Edit /etc/ssh/sshd_config
LogLevel VERBOSE
Restart the service
systemctl restart ssh

Transitioning to Certificate-Based Authentication

The ultimate way to secure SSH is to move away from static keys and passwords. SSH Certificates (not to be confused with SSL/TLS certificates) allow you to issue short-lived access tokens. This eliminates the risk of stolen id_rsa files and simplifies logging, as the certificate identity is logged directly.

Managing SSH Logs in Kubernetes and Containerized Hosts

In Kubernetes, we don't usually SSH into individual pods. However, we do SSH into the worker nodes. We use a DaemonSet to collect logs from the host's /var/log/auth.log and forward them to a central logging namespace. This ensures that even if a node is terminated, its SSH history is preserved in the SIEM.

Leveraging AI and Machine Learning for SSH Anomaly Detection

Modern SIEMs use Unsupervised Machine Learning to build a "baseline" of normal behavior. If a user who typically logs in from Bengaluru suddenly logs in from a VPN endpoint in the Netherlands, the ML engine assigns a "Risk Score" to that session. This allows analysts to prioritize investigations based on probability rather than static rules.

CVE-2024-6387: The 'regreSSHion' Vulnerability

We recently analyzed CVE-2024-6387, a signal handler race condition in OpenSSH. Exploitation attempts for this vulnerability often leave a specific pattern in the logs: multiple connection attempts that timeout or crash the sshd process without completing authentication. Monitoring for "Timeout before authentication" spikes is now a standard part of our SSH detection logic.

Searching for potential regreSSHion exploitation attempts
grep "Timeout before authentication" /var/log/auth.log | awk '{print $1, $2, $(NF-3)}' | uniq -c

Addressing the Indian SME Security Gap

In the Indian SME sector, many organizations utilize "E-way bill" or "GST" filing servers running legacy Linux distros (RHEL 6/7) with default SSH ports exposed. Our research indicates a high density of SSH brute-force traffic originating from compromised IoT devices within local ISP networks (e.g., ACT, BSNL). For these teams, a "Poor Man's SIEM" using GoAccess can provide immediate visibility without the cost of a full Splunk deployment.

Running GoAccess for real-time SSH log visualization
goaccess /var/log/auth.log --log-format=SYSLOG --real-time-html -o /var/www/html/ssh-stats.html

Next Command: tail -f /var/log/auth.log | awk '/Failed password/ {print $1, $2, $3, "User:" $(NF-5), "IP:" $(NF-3)}' to monitor live attacks on your local terminal while your SIEM handles the long-term correlation.