SSH-Server auf Angriffe prüfen.
Moin, ich habe einen öffentlich zugänglichen SSH-Server (tine). Dieser wird per autossh regelmäßig von meinem Arbeitsplatzrechner (mit Einverständnis des Arbeitgebers) kontaktiert. Zur Zeit habe ich folgende Sicherheitsmaßnahmen 1. Ein Login ist nur per public-key möglich. 2. Der Key der für autossh genutzt wird (und kein Passwort haben kann) ist für einen Benutzer, der als Shell /bin/false hat, so dass damit keiner Unfug treiben kann, außer Ports weiterzuleiten. Ich würde eigentlich gerne sicherstellen, dass nur Ports in die ein Richtung gefordert werden, also wenn ich mich intern an tine wende, dass die zum Firmenrechner geforwardet werden. Geht das? Das zweite was mir noch wichtiger ist. Wie kann ich erkennen, ob jemand versucht über meinen SSH-Server einzudringen? Bin dankbar für alle Hinweise (auch auf übersehene Sicherheitslücken) und sei es nur ein schlauer Google-Suchbegriff (ich habe keinen gefunden). Danke Niels -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SSH-Server auf Angriffe prüfen.
Ad 2006-09-09, Niels Stargardt <[EMAIL PROTECTED]> dixit: > Wie kann ich erkennen, ob jemand versucht über meinen SSH-Server > einzudringen? Bei mir zeigt ein grep sshd auth.log | grep Failed fehlgeschlagene Versuche an. Nur was nutzt diese Information? Und wenn der Zugang erfolgreich war, wird es in aller Regel bereits zu spaet gewesen sein. Grusz, Peter Blancke -- Hoc est enim verbum meum! -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SSH-Server auf Angriffe prüfen.
Hi, Am Samstag, den 09.09.2006, 11:36 +0200 schrieb Niels Stargardt: > Ich meine das PortForwarding. Durch den Tunnel soll mir zwar ein Port > angeboten werden, aber es soll nicht möglich sein vom Rechner der sich per > SSH einloggt, Ports zu meinem Rechner zu leiten. > > >> Das zweite was mir noch wichtiger ist. Wie kann ich erkennen, ob jemand > >> versucht über meinen SSH-Server einzudringen? Es gibt das nette Paket fail2ban. Das Untersucht die Logfiles und kann dann beispielsweise nach 5 fehlgeschlagenen SSH-Versuchen die betreffende IP für 10 Minuten mit Iptables sperren. Man kann über sie Sinnhaftigkeit von so was streiten, aber im Moment gibt es lästige Scripts, die versuchen verschiedene SSH-User abzuscannen. fail2ban kann übrigens auch apache, ftp und ein paar andere Sachen überwachen. > > Du koenntest Dir mit "logwatch" eine taegliche Zusammenfassung (nicht > > nur der SSH-Logins) schicken lassen. > Und was ist da der Suchbegriff? Mir ist selbst wenn ich mal einen Fehler > beim Login gemacht habe, nichts aufgefallen. Das hier ist aus meinem Logwatch: sshd: Authentication Failures: unknown (202.168.253.6): 1 Time(s) Invalid Users: Unknown Account: 1 Time(s) Sessions Opened: root by root: 4 Time(s) Die Statistik für SSH ist also schon eingebaut. Die rootlogins sind übrigens auch nur mit Schlüsseln möglich. Zudem solltest Du Dir mal die Manpage zu sshd_config anschauen. Da steht viel, wie man den Dienst absichern und konfigurieren kann. Greetz, Andre -- BOFH-excuse of the day: Browser's cookie is corrupted -- someone's been nibbling on it.
Re: SSH-Server auf Angriffe prüfen.
On Sat, 2006-09-09 at 11:10 +0200, Christian Schmidt wrote: > Niels Stargardt, 09.09.2006 (d.m.y): > Zusaetzlich koenntest Du mit iptables einen Paketfilter > drumherumstricken. Folgende 2 Zeilen könnten helfen: $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 2 -j DROP Dabei wird nach 2 fehlgeschlagenen Versuchen für 10 Min. keine weiteren Verbindungen mehr angenommen. Man kann natürlich auch die Anzahl der Versuche (--hitcount) und die Zeit (--seconds) beliebig ändern. Gruß Amir -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SSH-Server auf Angriffe prüfen.
On Sat, Sep 09, 2006 at 01:45:01PM +0200, Amir Tabatabaei wrote: > $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set > $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update > --seconds 600 --hitcount 2 -j DROP > > Dabei wird nach 2 fehlgeschlagenen Versuchen für 10 Min. keine weiteren > Verbindungen mehr angenommen. Woran bitte erkennt iptables das es sich um "fehlgeschlagenen Versuche" handelt? AFAIK wird nach jeder 2. ssh Verbindung für 10 Minuten jede weitere Verbindung dummerweise geDROPt. Warum eigentlich nicht REJECT? Besonders nervig wird das wenn man mit mehreren scp-Kommandos Daten von/auf so einen Computer kopieren will. -- Nicht Absicht unterstellen, wenn auch Dummheit ausreicht! pgp0yoGFIHlqS.pgp Description: PGP signature
Re: SSH-Server auf Angriffe prüfen.
On Sat, 2006-09-09 at 14:37 +0200, Martin Reising wrote: > On Sat, Sep 09, 2006 at 01:45:01PM +0200, Amir Tabatabaei wrote: > > $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set > > $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m recent > > --update --seconds 600 --hitcount 2 -j DROP > > > > Dabei wird nach 2 fehlgeschlagenen Versuchen für 10 Min. keine weiteren > > Verbindungen mehr angenommen. > > Woran bitte erkennt iptables das es sich um "fehlgeschlagenen > Versuche" handelt? Na gut, nach 2 *GanzEgalWasFür* Versuchen. Für mich war es bisher auf jeden Fall sehr hilfreich, Unerwünschte fernzuhalten. > AFAIK wird nach jeder 2. ssh Verbindung für 10 Minuten jede weitere > Verbindung dummerweise geDROPt. Warum eigentlich nicht REJECT? Weil ich nicht einem Angreifer unter die Arme greife! > Besonders nervig wird das wenn man mit mehreren scp-Kommandos Daten > von/auf so einen Computer kopieren will. Das mag stimmen. Er wollte aber lediglich EINMAL pro Tag PortForwarding machen! Amir -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SSH-Server auf Angriffe prüfen.
Hallo, Niels Stargardt wrote: > Moin, > ich habe einen öffentlich zugänglichen SSH-Server (tine). Dieser wird per > autossh regelmäßig von meinem Arbeitsplatzrechner (mit Einverständnis des > Arbeitgebers) kontaktiert. Zur Zeit habe ich folgende Sicherheitsmaßnahmen > > 1. Ein Login ist nur per public-key möglich. > > 2. Der Key der für autossh genutzt wird (und kein Passwort haben kann) ist > für einen Benutzer, der als Shell /bin/false hat, so dass damit keiner > Unfug treiben kann, außer Ports weiterzuleiten. > > Ich würde eigentlich gerne sicherstellen, dass nur Ports in die ein Richtung > gefordert werden, also wenn ich mich intern an tine wende, dass die zum > Firmenrechner geforwardet werden. Geht das? > > Das zweite was mir noch wichtiger ist. Wie kann ich erkennen, ob jemand > versucht über meinen SSH-Server einzudringen? schau Dir mal sshdfilter an, damit werden nach n-Fehlversuchen iptables Regeln erstellt, welche die IP blocken. Kann man gut als Grundlage für Anderes verwenden. Ansonsten als Alternative den sshd auf einen andren Port laufen lassen und schon ist Ruhe. hth Reinhold -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: SSH-Server auf Angriffe prüfen.
On Saturday 09 September 2006 14:48, Amir Tabatabaei wrote: > On Sat, 2006-09-09 at 14:37 +0200, Martin Reising wrote: > > On Sat, Sep 09, 2006 at 01:45:01PM +0200, Amir Tabatabaei wrote: > > > $IPTABLES -I INPUT -p tcp --dport 22 -m state --state NEW -m > > > recent --set $IPTABLES -I INPUT -p tcp --dport 22 -m state --state > > > NEW -m recent --update --seconds 600 --hitcount 2 -j DROP > > Na gut, nach 2 *GanzEgalWasFür* Versuchen. Für mich war es bisher auf > jeden Fall sehr hilfreich, Unerwünschte fernzuhalten. > > > AFAIK wird nach jeder 2. ssh Verbindung für 10 Minuten jede weitere > > Verbindung dummerweise geDROPt. Warum eigentlich nicht REJECT? > > Weil ich nicht einem Angreifer unter die Arme greife! > Durch diese Regel ist es aber sehr einfach möglich, eine Denial of Service Situation herzustellen, oder? Ich baue einfach alle paar Minuten eine Verbindung auf und schon kann sich niemand mehr am ssh daemon anmelden. IMO sollte sshd nicht auf port 22 lauschen, dann fallen die meisten 'seek and exploit' Angriffe ohnehin schonmal weg. Gruß, Andreas
Re: SSH-Server auf Angriffe prüfen.(Summary)
Niels Stargardt wrote: > Moin, > ich habe einen öffentlich zugänglichen SSH-Server (tine). Dieser wird per > autossh regelmäßig von meinem Arbeitsplatzrechner (mit Einverständnis des > Arbeitgebers) kontaktiert. Zur Zeit habe ich folgende Sicherheitsmaßnahmen > > 1. Ein Login ist nur per public-key möglich. > > 2. Der Key der für autossh genutzt wird (und kein Passwort haben kann) ist > für einen Benutzer, der als Shell /bin/false hat, so dass damit keiner > Unfug treiben kann, außer Ports weiterzuleiten. > > Ich würde eigentlich gerne sicherstellen, dass nur Ports in die ein > Richtung gefordert werden, also wenn ich mich intern an tine wende, dass > die zum Firmenrechner geforwardet werden. Geht das? > > Das zweite was mir noch wichtiger ist. Wie kann ich erkennen, ob jemand > versucht über meinen SSH-Server einzudringen? > > Ich fasse mal den bisherigen Thread zusammen um die noch offene Frage hervorzuheben. Soweit ich es verstanden habe, ist es nur bedingt möglich das PortForwarding einzuschränken auf bestimmte Ports oder Richtungen. Was gut geht sind bestimmte IP-Adressen auszusperren. OK. Um Angriffe zu Entdecken kann man die Firewall nutzen und bei mehreren Rejects den Port sperren, was für DoS-Attacken anfällig ist. Eleganter wäre da fail2ban. Alleine zum Feststellen tut es auch logwatch --service sshd --print. Beide setzen auf die Analyse der Log-Datei /var/log/auth.log. Mein Problem: Ich finde in der Datei nur Angriffe auf einen unbekannten Nutzer. Angriffe auf existierende Nutzer mit falschen Key finde ich nicht. Daher meine Vermutung, dass evtl. der SSH-Server falsch konfiguriert ist. Ich habe die man-Page noch mal studiert, aber keine Idee bekommen. Die Config könnt Ihr lesen unter http://rafb.net/paste/results/Ghd7ia53.html. Also wenn jemand weiß wie man es schafft Angriffe auf existierende Nutzer mit falschem oder gar keinem Key zu protokollieren wäre ich dankbar. Wenn ich den Log-Eintrag habe, denke ich bekomme ich auch fail2ban von backports installiert und konfiguriert. Danke Niels -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
