Tegenwoordig vinden we verschillende manieren om veilig verbinding te maken met onze servers om onderhouds- en ondersteuningstaken uit te voeren of om de status ervan te controleren. Omdat we niet altijd direct op de fysieke locatie kunnen zijn van dit de meest praktische en gebruikelijke manier om toegang te krijgen tot de server, is het op afstand mogelijk via het SSH-protocol.
SSH (Secure SHell) is ontwikkeld als een protocol waarmee verbindingen tussen twee systemen tot stand kunnen worden gebracht op basis van de client / server-architectuur, waardoor we als beheerders of gebruikers op afstand verbinding kunnen maken met de server of computer, een van de meest opvallende voordelen van SSH is dat het verantwoordelijk is voor het versleutelen van de verbindingssessie om de veiligheid te vergroten door te voorkomen dat aanvallers toegang krijgen tot niet-versleutelde wachtwoorden.
Nu wordt elke login of poging om toegang te krijgen tot de server met behulp van SSH gelogd en opgeslagen in een logbestand door de rsyslog-daemon op Linux, zodat het mogelijk is om toegang te krijgen en in detail te valideren wie, wanneer en de status van het opstarten van de sessie waardoor een veel completere audit- en controletaak mogelijk is.
Solvetic zal u in deze tutorial uitleggen hoe u dit bestand kunt bekijken en bepalen wie de computer heeft geprobeerd of heeft ingelogd.
1. Installeer SSH op Linux
Voor dit voorbeeld hebben we Ubuntu 19 en CentOS 8 gebruikt, onthoud dat bij toegang via SSH we uitgebreid op de computer kunnen werken:
VERGROTEN
Installeer SSH op CentOS 8Als je SSH in CentOS 8 wilt installeren, moet je het volgende uitvoeren:
yum -y installeer openssh-server openssh-clients
VERGROTEN
Installeer SSH op UbuntuAls u het in Ubuntu 19 wilt doen, moet u het volgende uitvoeren:
sudo apt install openssh-server
2. Gebruik het grep-commando om mislukte aanmeldingen op Linux te bekijken
Stap 1
De eenvoudigste manier om inlogpogingen te bepalen en te bekijken is door het volgende uit te voeren:
grep "Wachtwoord mislukt" /var/log/auth.log
Stap 2
We kunnen details zien zoals:
- Gebruiker probeert in te loggen
- IP adres
- Poort gebruikt voor de inlogpoging
Stap 3
We vinden hetzelfde resultaat met het cat-commando:
cat /var/log/auth.log | grep "Wachtwoord mislukt"
Stap 4
Als u aanvullende informatie wilt verkrijgen over de mislukte SSH-aanmeldingen in Linux, moeten we het volgende uitvoeren. Zoals we zien zijn de details veel completer.
egrep "Mislukt | Mislukt" /var/log/auth.log
Logboeken bekijken in RHEL of CentOS 8In het geval van RHEL of CentOS 8 zijn alle logboeken ondergebracht in het / var / log / secure bestand, voor hun visualisatie zullen we het volgende uitvoeren:
egrep "Mislukt | Mislukt" / var / log / secure
VERGROTEN
We zien dat de logs worden bijgehouden met volledige details, inclusief geregistreerde sessienamen (juist of niet). Een andere optie om mislukte SSH-aanmeldingen in CentOS te bekijken, is door een van de volgende regels te gebruiken:
grep "Mislukt" / var / log / secure grep "authenticatiefout" / var / log / secure
VERGROTEN
Stap 5
Om de lijst met IP-adressen weer te geven die toegang probeerden te krijgen, maar niet succesvol waren, moeten we de volgende opdracht gebruiken:
grep "Wachtwoord mislukt" /var/log/auth.log | awk '{print $ 11}' | uniq -c | sorteer -nr Stap 6In de meest recente Linux-distributies (zoals Ubuntu 19) is het mogelijk om toegang te krijgen tot het runtime-logbestand dat Systemd beheert met het journalctl-commando. Als we de mislukte SSH-logs willen zien, zullen we het grep-commando gebruiken om de resultaten als deze:
journalctl _SYSTEMD_UNIT = ssh.service | egrep "Mislukt | Mislukt" (Ubuntu) journalctl _SYSTEMD_UNIT = sshd.service | egrep "Mislukt | Mislukt" (RHEL, CentOS)
Op CentOSIn CentOS kunnen we ook het volgende gebruiken:
journalctl _SYSTEMD_UNIT = sshd.service | grep "mislukking" journalctl _SYSTEMD_UNIT = sshd.service | grep "Mislukt"
We kunnen zien hoe we elke mislukte SSH-inlogpoging kunnen bekijken en op basis hiervan de relevante beveiligingsmaatregelen kunnen nemen om de beschikbaarheid van services te behouden.
