Debug School

rakesh kumar
rakesh kumar

Posted on

How to Check Whether It’s an Attack, an Out-of-Memory Crash, or a Full Disk

Repeated downtime does not by itself mean someone hacked the server. Failed SSH attempts and suspicious web requests are common on public servers; the key is whether anyone successfully logged in and what happened at the time of each outage.

Run these read-only commands on the affected server. They do not delete logs or change settings.

Find when the server restarted or a service failed 

uptime
last -x reboot shutdown | head -30
sudo journalctl --list-boots
sudo journalctl -b -1 -p warning..alert --no-pager | tail -100
Enter fullscreen mode Exit fullscreen mode

-b -1 means the previous boot. If it says there is no previous boot, that journal may not have been retained. journalctl can filter by boot and severity.

Look for memory, disk, and service problems 

sudo journalctl -k --since "7 days ago" --no-pager | rg -i 'out of memory|oom|killed process|no space left|I/O error|ext4'
df -h
free -h
sudo systemctl --failed
Enter fullscreen mode Exit fullscreen mode

Your earlier screenshot mentioned no swap and possible OOM events, so the first command is especially useful. A failed service can indicate a crash or timeout; it is not automatically evidence of an attack.

Check SSH attempts and successful logins 

sudo journalctl --since "7 days ago" --no-pager | rg -i 'sshd.*(Failed password|Invalid user|Accepted password|Accepted publickey|session opened)' | tail -150
sudo zgrep -hEi 'sshd.*(Failed password|Invalid user|Accepted password|Accepted publickey)' /var/log/auth.log* | tail -150
last -ai | head -40
Enter fullscreen mode Exit fullscreen mode

The Accepted password and Accepted publickey lines deserve closer attention: compare their user, IP address, and time with logins you recognize. Repeated Failed password lines alone show attempts, not successful access. Use whichever log source actually has records on your server.

  1. Search XAMPP Apache logs for common probes

First see which log files exist:

sudo find /opt/lampp/logs -maxdepth 2 -type f -printf '%p\n' | head -60
Enter fullscreen mode Exit fullscreen mode

Then, if /opt/lampp/logs/access_log and error_log exist:

sudo rg -i -m 100 'wp-admin|wp-login|\.env|/vendor/phpunit|/cgi-bin|/server-status|/actuator|/\.git|/etc/passwd' /opt/lampp/logs/access_log
Enter fullscreen mode Exit fullscreen mode 
sudo rg -i -m 100 'AH[0-9]+|segfault|fatal|permission denied|server reached MaxRequestWorkers' /opt/lampp/logs/error_log
Enter fullscreen mode Exit fullscreen mode

A request for .env or wp-admin indicates a probe, not proof it succeeded. Apache’s error log is also a key place to investigate why Apache stopped or failed to serve requests.

Start by sending the output of sections 1 and 2, plus any unfamiliar Accepted SSH lines from section 3. You can mask public IPs if needed, but keep the timestamps, usernames, and message text so we can correlate them with the downtime.

chat

Top comments (0)