Is jouw SSH-server veilig? Uitgebreide analyse van hacking-indicatoren in SSH-serverlogboeken

De kans is groot dat jouw SSH-server al honderden keren per dag aangevallen wordt. Het gebruik van het woord groot is een understatement. Ik ben ervan overtuigd dat jouw server vrijwel zeker honderden aanvallen per dag ondergaat.Desondanks bekijken veel ontwikkelaars de /var/log map nauwelijks. Voer nu eens een simpele journalctl -f |grep ssh uit in de terminal.

Als je de logs goed bekijkt:

• Wie

• Wanneer

• Waar

• Hoe
  ze probeerden in te loggen op de server, wordt duidelijk zichtbaar.

In dit artikel geef ik een overzicht vanuit het perspectief van een ontwikkelaar over hoe je SSH-serverlogs kunt interpreteren en echte hacking-indicatoren kunt ontdekken.

1. Waar worden SSH-logs opgeslagen?

De locatie van SSH-logs verschilt een beetje per Linux-distributie.

Over het algemeen:

• Ubuntu / Debian-gebaseerd

  • /var/log/auth.log

• CentOS / RHEL-gebaseerd

  • /var/log/secure

• gemeenschappelijke systemd-opdrachten

  • journalctl -u ssh.service of journalctl -u sshd

Je kunt tail gebruiken, maar persoonlijk geef ik de voorkeur aan het bekijken via journald. Dit komt omdat je de logs van alle services op één plek kunt bekijken.

# Voorbeeld voor Ubuntu
sudo tail -f /var/log/auth.log

# Voorbeeld voor CentOS/RHEL
sudo tail -f /var/log/secure

# Live bekijken van systemd service logs
sudo journalctl -u ssh.service -f

tip: Zelfs op een ontwikkelserver is het goed om af en toe de gewoonte aan te nemen om logs te “bewaken” met tail -f.

Klik "hier" voor meer informatie over het gebruik van journald!

2. Een regel van de SSH-log ontleden

Laten we een typische regel uit SSH-logs bekijken om de structuur te begrijpen. (Voorbeeld voor Ubuntu)

2.1 Succesvolle aanmelding met een openbare sleutel

Jan 10 12:34:56 myserver sshd[12345]: Accepted publickey for deploy from 203.0.113.10 port 50312 ssh2: ED25519 SHA256:xxxx

De betekenis van elke sectie:

• Jan 10 12:34:56 : Datum, tijd

• myserver : Hostnaam

• sshd[12345] : Procesnaam (SSH-daemon) en PID

• Accepted publickey : Succevolle authenticatie, methode is openbare sleutel

• for deploy : Naam van het inlogaccount

• from 203.0.113.10 : IP-adres van de verbinding

• port 50312 : Clientzijde poort

• ssh2: ED25519 ... : Protocol-/sleuteltype-informatie

Als je dit begrijpt, kun je snel bepalen “wie en van waar met welke sleutel is ingelogd”.

2.2 Mislukte aanmelding met een wachtwoord

Jan 10 12:35:01 myserver sshd[12346]: Failed password for root from 198.51.100.23 port 50320 ssh2

• Failed password : Mislukte wachtwoordauthenticatie

• for root : Poging met het root-account

• from 198.51.100.23 : Afstands-IP

Als deze logs tientallen tot honderden keren op korte tijd voorkomen,
is het vrijwel zeker een brute-force-aanval.

2.3 Poging tot inloggen met een niet-bestaande gebruiker

Jan 10 12:35:05 myserver sshd[12347]: Invalid user admin from 198.51.100.23 port 50325

• Invalid user admin : Poging tot inloggen met het admin account dat niet op de server bestaat

Dit is ook een patroon dat vaak door geautomatiseerde bots wordt gebruikt.

3. Typische aanvalspatronen aan de hand van logs

3.1 Brute-force aanval

Kenmerken:

• Failed password logs komen in korte tijd zeer veel voor

• Verschillende pogingen van hetzelfde IP-adres

• Accountnamen zoals root, admin, test, oracle worden gebruikt

Snel controlevoorbeeld:

# Totaal aantal Failed password
sudo grep "Failed password" /var/log/auth.log | wc -l

# Welk account het meest aangevallen wordt
sudo grep "Failed password" /var/log/auth.log \
  | awk '{for (i=1;i<=NF;i++) if ($i=="for") print $(i+1)}' \
  | sort | uniq -c | sort -nr | head

3.2 Scannen naar niet-bestaande gebruikers

sudo grep "Invalid user" /var/log/auth.log | head

Als er veel van deze logs zijn, betekent dit dat er gewoon een poging gedaan wordt om te raden welke accounts op deze server bestaan.

3.3 Overmatige pogingen van een specifiek IP-adres

Controleer welke IP's bijzonder vaak falen:

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

Hier is $(NF-3) gewoonlijk het IP dat naar from <IP> verwijst,
maar het kan iets verschillen per omgeving, dus je moet het aanpassen aan je eigen logformat.

4. Ongewone signalen vinden tussen “succesvolle” aanmeldingen

Aanvallen blijven meestal mislukt, maar het echt verontrustende zijn de succesvolle aanmeldingen.

4.1 Geaccepteerde logs verzamelen

sudo grep "Accepted" /var/log/auth.log

Geef bijzondere aandacht aan:

• Toegang met accounts die normaal niet gebruikt worden

• Toegang op ongebruikelijke tijdstippen (bijv. 3 uur 's nachts)

• IP-adressen uit ongebruikelijke landen/segmenten (niet vanuit het bedrijf/thuis/VPN)

4.2 Bekijk recente aanmeldgeschiedenis in één keer

De last opdracht toont de recente aanmeldgeschiedenis.

# Recente SSH-aanmeldingen
last -i | head

# Mislukte aanmeldingen (in ondersteunde omgevingen)
lastb | head

sudo grep "Failed password" /var/log/auth.log | wc -l
sudo grep "Invalid user" /var/log/auth.log | wc -l

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

sudo grep "Failed password for root" /var/log/auth.log | tail
sudo grep "Accepted.*root" /var/log/auth.log

sudo grep "Accepted" /var/log/auth.log | tail -n 50

PasswordAuthentication no
PubkeyAuthentication yes

sudo systemctl reload sshd
# of
sudo service ssh restart

PermitRootLogin no

Port 22    # -> bijvoorbeeld naar: 2222

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp
sudo ufw deny 22/tcp