pam_tally2 zählt keine Fehler über SSH

pam_tally2 zählt keine Fehler über SSH

Ich habe Zeile hinzugefügt

auth required pam_tally2.so deny=3 unlock_time=180

zu meiner /etc/pam.d/loginDatei, und das ist in TTY alles in Ordnung, testuserwird aber nach drei Versuchen angehalten.

Allerdings erzeugt genau diese Zeile /etc/pam.d/sshdkeinerlei Effekt.

xieerqi:$ ssh testuser@localhost
Password: 
Password: 
Password: 
Permission denied (publickey,keyboard-interactive).

xieerqi:$ ssh testuser@localhost                                                                                           
Password: 
Password: 
Password: 
Permission denied (publickey,keyboard-interactive).

Wie Sie sehen, kann der Benutzer auch nach drei erfolglosen Versuchen immer noch versuchen, das Passwort einzugeben.

Wie kann ich ssheinen Benutzer nach 3 Verstößen sperren?

Antwort1

Für SSH ist es vielleicht besser, etwas anderes als pam zu verwenden. Es gibt eine großartige Lösung, die über iptables und die sshd_configDatei bereitgestellt wird. Dies ist nur eine Möglichkeit, das gewünschte Ergebnis zu erzielen. Laut Dokumentation wird normalerweise empfohlen, SSH-Schlüssel anstelle einer Überprüfung der Authentifizierungsmethode mit einem Passwort zu verwenden.https://help.ubuntu.com/community/SSH/OpenSSH/Configuring.

  1. Sie müssten das /etc/ssh/sshd_configHinzufügen der Zeile ändern

    MaxAuthTries 1
    
  2. Sie müssen die folgenden Firewall-Regeln erstellen

    • Erstellen einer neuen Kette

      iptables -N SSHATTACK   
      iptables -A SSHATTACK -j LOG --log-prefix "Possible SSH attack! " --log-level 7  
      iptables -A SSHATACK -j DROP  
      
    • Blockieren Sie für 120 Sekunden jede IP-Adresse, die mehr als drei Verbindungen innerhalb von 120 Sekunden aufbaut. Beim vierten Verbindungsversuch wird die Anfrage an die SSHATTACK-Kette delegiert, die für die Protokollierung des möglichen SSH-Angriffs verantwortlich ist und die Anfrage schließlich verwirft.

      iptables -A INPUT -i eth0 -p tcp -m state --dport 22 --state NEW -m recent --set     
      iptables -A INPUT -i eth0 -p tcp -m state --dport 22 --state NEW -m recent --update --seconds 120 --hitcount 4 -j SSHATTACK    
      
  3. Sie können die für die Datei unternommenen Versuche überprüfen /var/log/syslog.

Antwort2

Die übliche Vorgehensweise besteht darin, fail2bandas auf Netzwerkebene statt auf PAM-Ebene funktioniert und Ihre Ressourcen für die gesamte von durchgeführte Kryptographie spart sshd.

Haben Sie nach der fehlgeschlagenen Authentifizierung trotzdem versucht, das richtige Passwort einzugeben? Wird es akzeptiert? Was wird angemeldet /var/log/auth.log?

sshdDer Server führt immer den gesamten PAM-Stapel aus, auch wenn der Benutzer nicht existiert, angehalten oder gesperrt ist, um Angriffe über Seitenkanäle (z. B. Identifizierung vorhandener Benutzer) auszuschließen. Dies ist das Problem, auf das Sie stoßen. Es kann funktionieren, aber sshaus Sicherheitsgründen können Sie es nicht durchsehen.

Antwort3

Versuchen Sie, die Reihenfolge der Zeilen zu ändern. PAM führt sie dann nacheinander aus.
Beispiel:
/etc/pam.d/common-auth

auth    required                        pam_tally2.so deny=3 onerr=fail unlock_time=300 debug
auth    [success=1 default=ignore]      pam_unix.so nullok
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

funktioniert bei mir.

verwandte Informationen