Hier mal eine Zusammenfassung bzgl. der Angriffe via SSH. SSH ist mit 809 weltweit freigeschalteten IP-Adressen nach HTTPS (1333) und HTTP (1122) auf Platz drei der Freischaltungsrangliste in der RWTH-Firewall. Dazu kommen noch 60 Server auf anderen Ports bzw. mit reduzierten (auf DE+BeNeLux) Freischaltungen. Teilweise werden diese Freischaltungen in nachgelagerten ACLs auf den Routern reduziert. * Wünschenswert wäre hier sicherlich mehr Server in der DE+BeNeLux Gruppe zu haben, als diese weltweit zu exponieren. * Bei den gescannten Diensten ist SSH (wie auch RDP) eigentlich immer in den Top10, Top ist hier (mit Abstand) Telnet, gefolgt von HTTP. Quellen der Scans sind zu großen Teilen Würmer auf Geräten der Klasse IoT, also Home-Router, IP-Kameras, Video-Abspieler und SAT-Empfänger, usw. Diese versuchen dann per Brute-Force weitere Geräte zu finden, meist mit Standard Credentials. Eine besondere Rolle spielen hierbei ältere Raspberry PI, da diese meist mit Defaultpassworten betrieben wurden. Wir hatten in den letzten 3 Jahren vier Zwischenfälle mit SSH, die im wesentlichen 2 Ursachen hatten: a) leichtsinnig gesetztes simples Passwort b) kein Bewusstsein dafür, dass diese IP weltweit erreichbar ist Auf dem Logserver checkpoint.rz filtern wir SSH bezogene Logs in eine Datei rein, hier mal so eine Grobauswertung der 280K Zeilen aus diesen Logs (April 2020): Management System NOC: 50K Security Scanner: 22K Monitoring RZ-Cluster: 14K Cisco-ACLs IPv4: 49K Failed Password: 59K Refused Connect (Wrapper): 75K Invalid User: 9K Management Institut: 3K Cisco-ACLs IPv6: 1K RWTH-Firewall: 1K (gibt in der Summe Rundungsfehler)
Ohai, On 17.04.20 12:24, Jens Hektor wrote:
Hier mal eine Zusammenfassung bzgl. der Angriffe via SSH. Habt ihr Zahlen, wie viele der freigeschalteten Systeme überhaupt ein SSH-Login per Passwort zulassen? "PermitRootLogin prohibit-password" ist ja inzwischen selbst in debian stable Standard, das "PasswordAuthentication no" muss man aber leider noch selber setzen.
Gruß Markus
On Fri, Apr 17, 2020 at 12:47:38PM +0200, Jens Hektor wrote:
Am 17.04.20 um 12:45 schrieb Markus Witt:
Habt ihr Zahlen, wie viele der freigeschalteten Systeme überhaupt ein SSH-Login per Passwort zulassen?
Ich nicht.
Falls jemand seine eigenen Rechner scannen möchte: https://coolaj86.com/articles/testing-if-ssh-allows-passwords/ Das ssh-Kommando habe ich mir angeschaut uns ausprobiert, das sieht vernünftig aus. Den node.js-Kram habe ich mir nicht angeschaut. Grüße, Jan
Dann stellt sich jetzt doch die Frage, soll man ein Good Practice einführen, welches ein login per Kennwort generell nicht zulässt. Bei den Security Scans, die vom it-center durchgeführt werden, ist ja auch eine deutliche Tendenz nach unten erkennbar gewesen, was den durchschnittlichen Wert anging. Technisch machbar ist das ja, man muss nur seine Benutzer erziehen, das nicht über Kennwort zu machen und eventuell Hilfestellung beim Erstellen der Keys zu geben. Und es muss ja nicht bis übermorgen passieren. Da wäre dann auch eine Richtlinie des ITC hilfreich. Ihr habt ja auch erfolgreich damit angefangen, das mit der Portsperrung jenseits von 1024 anzugehen. Und ich glaube, dass mittlerweile da alle gut mit leben können. Das Szenario "ich bin Gastwissenschaftler mit einem festen Arbeitsplatz anderswo und möchte ssh in die RWTH machen und habe gerade nicht den Cisco VPN Client installiert kann aber einen key per usb importieren" könnte gegen VPN sprechen. Diese Good Practice liesse sich ja auch auf weitere Ports/Dienste erweitern. Ich bin ja auch manchmal etwas träge, was Sicherheit angeht, wenn ein Assistent oder Professor ankommt und sagt, ich brauche das jetzt. Da helfen dann Richtlinien von wegen, wir machen das jetzt so. Corona zeigt ja gerade, dass das von oben durchaus vorgegeben werden kann und die meisten das dann auch befolgen. Viele Grüße Frank Knoben On 17.04.20 12:54, Jan Niehusmann wrote:
On Fri, Apr 17, 2020 at 12:47:38PM +0200, Jens Hektor wrote:
Am 17.04.20 um 12:45 schrieb Markus Witt:
Habt ihr Zahlen, wie viele der freigeschalteten Systeme überhaupt ein SSH-Login per Passwort zulassen? Ich nicht. Falls jemand seine eigenen Rechner scannen möchte: https://coolaj86.com/articles/testing-if-ssh-allows-passwords/
Das ssh-Kommando habe ich mir angeschaut uns ausprobiert, das sieht vernünftig aus. Den node.js-Kram habe ich mir nicht angeschaut.
Grüße, Jan _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann? Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu. Viele Grüße Frank Knoben
Das waere kein Problem. Zum einen hast du ja den Fingerprint des Servers, und beim Mismatch geht die Verbindung nicht weiter. Selbst wenn du den ignorierst, waere das mit Pubkey-Auth kein Problem. Das Ding macht Challenge-Response und der gesignedte Blob hat u.a. auch teile deiner und der Server-Nonce drinne. Da funktioniert kein MITM. Schon versucht :D Viele Gruesse Florian On Fri, 17 Apr 2020 13:16:19 +0200 Frank Knoben <admin@igpm.rwth-aachen.de> wrote:
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann?
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Viele Grüße
Frank Knoben _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Ohai, weil mich das gerade auch noch im Detail interessiert hat, nochmal kurz zwei Links: In [0] wird beschrieben, dass der Client zur Authentifizierung gegenüber dem Server u.a. einen session identifier signiert. Nach [RFC4252] ist der session indentifier der "exchange hash H" des ersten key exchange, in den nach [RFC4253] für DH und [RFC5656] für ECC der öffentliche Key des Servers einfließt. Solange der MITM also nicht den privaten Key des Zielservers hat, kann er den Client nur einen session identifier signieren lassen, für den er die restlichen sessionkeys nicht kennt (bei passivem MITM, also nur Mitschneiden) oder bei dem dann der public key des echten Servers nicht enthalten ist (aktives MITM). Gruß Markus [0] <https://www.gremwell.com/ssh-mitm-public-key-authentication> [RFC4252] <https://tools.ietf.org/html/rfc4252> [RFC4253] <https://tools.ietf.org/html/rfc4253#page-23> [RFC5656] <https://tools.ietf.org/html/rfc5656#page-7> On 17.04.20 13:22, Florian Kerber wrote:
Das waere kein Problem.
Zum einen hast du ja den Fingerprint des Servers, und beim Mismatch geht die Verbindung nicht weiter.
Selbst wenn du den ignorierst, waere das mit Pubkey-Auth kein Problem. Das Ding macht Challenge-Response und der gesignedte Blob hat u.a. auch teile deiner und der Server-Nonce drinne. Da funktioniert kein MITM. Schon versucht :D
Viele Gruesse
Florian
On Fri, 17 Apr 2020 13:16:19 +0200 Frank Knoben <admin@igpm.rwth-aachen.de> wrote:
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann?
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Viele Grüße
Frank Knoben _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Das klappt selbst dann nicht, wenn der Angreifer den privaten Hostkey des Zielrechners hat und aktives MITM betreibt. Hab den Sourcecode von SSH vor Jahren mal zerlegt, weil ich genau das machen wollte. https://tools.ietf.org/html/rfc4251#section-9.3.3 -> hier wird zwar Replay beschrieben, aber laesst sich selbst auf aktives MITM anwenden In der session_id ist u.a. random Kram aus dem DH-Exchange drin, an den du - selbst mit Wissem um den Private Host Key - nicht drankommst :D Der Client kauft dir ab, dass du der Server bist, aber der echte Server laesst dich mit dem gesignten Blob nicht rein, weil die session_id zwischen dir und dem Client und dir und dem echten Server nicht gleich ist. Und da du nur einen Teil der session_id beeinflussen kannst, schaffst du es auch nicht, die bei beiden Verbindungen gleich zu machen. Der Angreifer kommt so nicht auf den echten Server, aber ein Problem bleibt. Du glaubst, du bist auf deinem Server. Je nachdem, welche Dateien du pushst koennte das ein Problem sein. Schoenes Wochenende :D Florian On Fri, 17 Apr 2020 13:53:16 +0200 Markus Witt <markus.witt@rwth-aachen.de> wrote:
Ohai,
weil mich das gerade auch noch im Detail interessiert hat, nochmal kurz zwei Links: In [0] wird beschrieben, dass der Client zur Authentifizierung gegenüber dem Server u.a. einen session identifier signiert. Nach [RFC4252] ist der session indentifier der "exchange hash H" des ersten key exchange, in den nach [RFC4253] für DH und [RFC5656] für ECC der öffentliche Key des Servers einfließt. Solange der MITM also nicht den privaten Key des Zielservers hat, kann er den Client nur einen session identifier signieren lassen, für den er die restlichen sessionkeys nicht kennt (bei passivem MITM, also nur Mitschneiden) oder bei dem dann der public key des echten Servers nicht enthalten ist (aktives MITM).
Gruß Markus
[0] <https://www.gremwell.com/ssh-mitm-public-key-authentication> [RFC4252] <https://tools.ietf.org/html/rfc4252> [RFC4253] <https://tools.ietf.org/html/rfc4253#page-23> [RFC5656] <https://tools.ietf.org/html/rfc5656#page-7>
On 17.04.20 13:22, Florian Kerber wrote:
Das waere kein Problem.
Zum einen hast du ja den Fingerprint des Servers, und beim Mismatch geht die Verbindung nicht weiter.
Selbst wenn du den ignorierst, waere das mit Pubkey-Auth kein Problem. Das Ding macht Challenge-Response und der gesignedte Blob hat u.a. auch teile deiner und der Server-Nonce drinne. Da funktioniert kein MITM. Schon versucht :D
Viele Gruesse
Florian
On Fri, 17 Apr 2020 13:16:19 +0200 Frank Knoben <admin@igpm.rwth-aachen.de> wrote:
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann?
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Viele Grüße
Frank Knoben _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Moin, On Fri, Apr 17, 2020 at 04:39:16PM +0200, Jens Hektor wrote:
Am 17.04.20 um 13:16 schrieb Frank Knoben:
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Dagegen gibts aber was: SSH Fingerprint Records im DNS.
Hilft das wirklich? Oder eher im Gegenteil? Ich meine, wenn ich mich _nicht_ vertippe, "ssh server.rwth-aachen.de" mache, und da antwortet dann irgendein MITM, dann hilft mir der Host Fingerprint, und wenn ich den nicht auswendig kenne, dann hilft mir der passende DNS-Record (vorausgesetzt man hat DNSSEC oder der MITM kann zufällig nur SSH und nicht DNS angreifen). Aber wenn ich mich beim Hostnamen vertippe und "ssh server.rwth-aache.de" eingebe, was hindert dann den Angreifer daran, einen passenen DNS-Eintrag mit dem dort tatsächlich verwendeten SSH-Key anzubieten? Da hilft mir dann auch kein DNSSEC mehr. Und ich bekomme noch nichtmal mehr eine Warnung über einen unbekannten Host-Key. (Bei VerifyHostKeyDNS=yes) Ich denke, das ist eher ein Nachteil an den SSHFP-Einträgen. Grüße, Jan
Ohai, On 17.04.20 16:58, Jan Niehusmann wrote:
Aber wenn ich mich beim Hostnamen vertippe und "ssh server.rwth-aache.de" eingebe, was hindert dann den Angreifer daran, einen passenen DNS-Eintrag mit dem dort tatsächlich verwendeten SSH-Key anzubieten? Nichts. Aber dadurch kann sich der Angreifer auch nicht gegenüber dem echten System authentifizieren, wie schon von Florian und mir vorhin ausgeführt. Er könnte also höchstens vortäuschen, dass man sich auf dem richtigen System befindet, was vielleicht noch kritisch wird, wenn man gerade das root-Passwort oder Konfigurationsdateien mit secrets ändert.
Ansonsten hilft gegen das Vertippen eine ~/.ssh/config oder sonstige Konfigurationsoptionen des ssh-Client der Wahl. Gruß Markus
Hi, On Fri, Apr 17, 2020 at 05:08:08PM +0200, Markus Witt wrote:
On 17.04.20 16:58, Jan Niehusmann wrote:
Aber wenn ich mich beim Hostnamen vertippe und "ssh server.rwth-aache.de" eingebe, was hindert dann den Angreifer daran, einen passenen DNS-Eintrag mit dem dort tatsächlich verwendeten SSH-Key anzubieten? Nichts. Aber dadurch kann sich der Angreifer auch nicht gegenüber dem echten System authentifizieren, wie schon von Florian und mir vorhin ausgeführt.
Das habe ich auch gar nicht bezweifelt. Ich bezog mich nur auf Jens Aussage, dass SSHFP-Records helfen könnten. Grüße, Jan
Hallo zusammen On 4/17/20 12:54 PM, Jan Niehusmann wrote:
Falls jemand seine eigenen Rechner scannen möchte: https://coolaj86.com/articles/testing-if-ssh-allows-passwords/
Das ssh-Kommando habe ich mir angeschaut uns ausprobiert, das sieht vernünftig aus ...
Jepp kurze (jedoch nicht sicherheitsrelevante) Info [0] an dieser Stelle zu public key "... When ssh tries to authenticate via public key, it sends the server all your public keys, one by one, until the server accepts one ..." VG Bernd [0] https://github.com/FiloSottile/whoami.filippo.io -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler@itc.rwth-aachen.de www.itc.rwth-aachen.de
Hallo zusammen, Am 17.04.20, 12:24 schrieb "Jens Hektor" <hektor@itc.rwth-aachen.de>:
* Wünschenswert wäre hier sicherlich mehr Server in der DE+BeNeLux Gruppe zu haben, als diese weltweit zu exponieren. *
Was spricht dagegen, die ssh-Zugänge nur fürs RTWH-Netz incl. VPN freizugeben? Wer ssh bedienen kann, sollte IMHO auch in der Lage sein, seinen VPN-Client zu starten. Beste Grüße, Robert -- Institute of Mineral Engineering (GHI) RWTH Aachen University (RWTH) Mauerstr. 5, D-52056 Aachen Tel.: +49-241-8095097 Fax: +49-241-80695097
Hallo zusammen, zum Beispiel eine Continuous Integration-Pipeline bei GitLab.com, die via SCP automatisch deployed, wenn im Repo vom Verbundprojekt auf den Master gepusht wird. Beste Grüße Matthias -----Ursprüngliche Nachricht----- Von: Prieler, Robert <prieler@ghi.rwth-aachen.de> Gesendet: Freitag, 17. April 2020 13:02 An: rwth-security@lists.rwth-aachen.de Betreff: [rwth-security] Re: Status SSH Hallo zusammen, Am 17.04.20, 12:24 schrieb "Jens Hektor" <hektor@itc.rwth-aachen.de>:
* Wünschenswert wäre hier sicherlich mehr Server in der DE+BeNeLux Gruppe zu haben, als diese weltweit zu exponieren. *
Was spricht dagegen, die ssh-Zugänge nur fürs RTWH-Netz incl. VPN freizugeben? Wer ssh bedienen kann, sollte IMHO auch in der Lage sein, seinen VPN-Client zu starten. Beste Grüße, Robert -- Institute of Mineral Engineering (GHI) RWTH Aachen University (RWTH) Mauerstr. 5, D-52056 Aachen Tel.: +49-241-8095097 Fax: +49-241-80695097
Ohai, "Prieler, Robert" <prieler@ghi.rwth-aachen.de> writes:
Was spricht dagegen, die ssh-Zugänge nur fürs RTWH-Netz incl. VPN freizugeben? Wer ssh bedienen kann, sollte IMHO auch in der Lage sein, seinen VPN-Client zu starten.
AnyConnect/OpenConnect ist totaler Murks. Und IPsec, was man eigentlich schön (sprich IKEv2) machen könnte, kann ja Cisco leider nicht (oder das RZ wirft nicht genug Münzen ein). Wenn ich ein anständiges VPN habe, z. B. OpenVPN ins Fachschaftsnetz, gerne, aber so drehe ich das ganze lieber auf links und mach einen SSH-Tunnel, statt mich mit diesem VPN rumzuschlagen. Und Passwort-Authentifizierung abschalten ist vielleicht bei entsprechenden User eine gute Idee, wird aber bei uns leider nix – es ist schwer genug, den Leuten FileZilla und SFTP beizubringen, Key ist denen leider zu kompliziert. --Thomas -- Fachschaft I/1 Mathematik/Physik/Informatik der RWTH Aachen Thomas Schneider Campus Mitte: Augustinerbach 2a, 52062 Aachen Telefon: +49 241 80 94506 Informatikzentrum: Ahornstraße 55, Raum 2014, 52074 Aachen Telefon: +49 241 80 26741 https://www.fsmpi.rwth-aachen.de
Hey, bei uns wird es Komplett gemacht mit Key! Wir lassen keine Passworte zu. Nicht einmal vom RWTH-Aachen Netz. Da ich trauriger weis Feststellen musste, dass der Netzwerkraum von einem ganzen Gebäude für jeder offen Stand/steht! Mal sehen, wie lange mein Ticket bezüglich dem Netzwerkraum noch in Bearbeitung steht! ;-) Mit freundlichen Grüßen, Benedikt Meier RWTH Aachen University Operations Research Kackertstr. 7, 2.OG, Raum B253 52072 Aachen Tel.: +49 241 80 93381 Web: https://www.or.rwth-aachen.de On 17/04/2020 14:05, Thomas Schneider wrote:
Ohai,
"Prieler, Robert" <prieler@ghi.rwth-aachen.de> writes:
Was spricht dagegen, die ssh-Zugänge nur fürs RTWH-Netz incl. VPN freizugeben? Wer ssh bedienen kann, sollte IMHO auch in der Lage sein, seinen VPN-Client zu starten.
AnyConnect/OpenConnect ist totaler Murks. Und IPsec, was man eigentlich schön (sprich IKEv2) machen könnte, kann ja Cisco leider nicht (oder das RZ wirft nicht genug Münzen ein). Wenn ich ein anständiges VPN habe, z. B. OpenVPN ins Fachschaftsnetz, gerne, aber so drehe ich das ganze lieber auf links und mach einen SSH-Tunnel, statt mich mit diesem VPN rumzuschlagen.
Und Passwort-Authentifizierung abschalten ist vielleicht bei entsprechenden User eine gute Idee, wird aber bei uns leider nix – es ist schwer genug, den Leuten FileZilla und SFTP beizubringen, Key ist denen leider zu kompliziert.
--Thomas
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Moin, On Fri, Apr 17, 2020 at 02:05:28PM +0200, Thomas Schneider wrote:
Und Passwort-Authentifizierung abschalten ist vielleicht bei entsprechenden User eine gute Idee, wird aber bei uns leider nix – es ist schwer genug, den Leuten FileZilla und SFTP beizubringen, Key ist denen leider zu kompliziert.
Was ein Glück, dass man bei so einer Zielgruppe natürlich davon ausgehen kann, dass sie ein sicheres Passwort verwenden, und für jeden Dienst ein anderes.
Fachschaft I/1 Mathematik/Physik/Informatik der RWTH Aachen
Hmm... Grüße, Jan
Hallo, meine größte Sorge Public-Key-Authentifizierung auf dem Server zu erzwingen wäre, wie man dann auch alle Anwender dazu erzieht den private key mit einem starken Passwort zu schützen und gegebenenfalls einen SSH-Agent zu verwenden. Andernfalls ist der private key IMHO nur so vertrauenswürdig wie der Rechner, auf dem er genutzt wird und wenn die Prämisse schon "Public- Key-Authentifizierung weil unsichere Passwörter" ist ... Verlagere ich das Problem damit nicht nur? Wie wird so etwas in anderen Einrichtungen / Instituten gehandhabt? Auf der anderen Seite schätze ich das Risiko für einen erfolgreichen SSH-Login via Passwörter durchprobieren für sehr gering ein, wenn im Vorfeld gängige security best practices umgesetzt werden, u.a. * Forcieren von Passwortrichtlinien * Automatische Sperrung von Benutzerkonten nach X fehlgeschlagenen Logins Gibt es einen guten Grund seine Linuxserver nicht entsprechend mit PAM und Modulen wie pam_faillock oder pam_tally zu schützen? Grüße, René -- René Xhonneux Dezernat Informationstechnologie (IT) IT-Service Universitätsbibliothek RWTH Aachen University Templergraben 61 52062 Aachen Tel: +49 241 80-94560 Fax: +49 241 80-92273 xhonneux@ub.rwth-aachen.de www.ub.rwth-aachen.de Sprechstunden: Mo. - Fr.: 09:00-15:00 Uhr
Hallo René, aus meiner Sicht ist es eigentlich egal, ob der private Key mit Passwort geschützt ist oder nicht. Da man den Key erstmal haben muss. Und solange der Key nicht irgendwo verteilt wird oder "mitgenommen" wird, ist das deutlich sicherer als mit einem Passwort. Natürlich ist auch besser, den Key mit einem Passwort zu sichern, dann hat man ja zwei Hürden: Man muss den private Key haben und muss dazu das Passwort kennen. Aber allein in den Besitz eines solchen Keys zu kommen sollte nicht ganz einfach sein. Ich persönliche sichere meinen privaten Server noch mit fail2ban [0] ab. Da beobachte ich das SSH Log und sehe, wer sich dort versucht wie anzumelden. Sollten zu viele Login Versuche passieren, so wird die entsprechende IP für 2h per iptables gebannt. So kann man auch recht gut einem gezielten Angriff entgegen wirken. Die Anzahl der Versuche und Sperrdauer ist dabei leicht anzupassen, würde mit kurzen Zeiten anfangen und das dann irgendwann verlängern. Man kann auch, wie ich es gemacht habe, mit zwei Jails arbeiten: Einem kurzen und bei wiederholten Verstößen, einen langen Jail. Im kurzen sind es wenige Stunden, im langen 2 Tage sperre. Gruß Stephan [0] https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_abs... -- Stephan Krinetzki IT Center Gruppe: Systemgruppe Linux Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki@itc.rwth-aachen.de www.itc.rwth-aachen.de -----Original Message----- From: Xhonneux, René <xhonneux@ub.rwth-aachen.de> Sent: Friday, April 17, 2020 3:00 PM To: rwth-security@lists.rwth-aachen.de Subject: [rwth-security] Re: Status SSH Hallo, meine größte Sorge Public-Key-Authentifizierung auf dem Server zu erzwingen wäre, wie man dann auch alle Anwender dazu erzieht den private key mit einem starken Passwort zu schützen und gegebenenfalls einen SSH-Agent zu verwenden. Andernfalls ist der private key IMHO nur so vertrauenswürdig wie der Rechner, auf dem er genutzt wird und wenn die Prämisse schon "Public- Key-Authentifizierung weil unsichere Passwörter" ist ... Verlagere ich das Problem damit nicht nur? Wie wird so etwas in anderen Einrichtungen / Instituten gehandhabt? Auf der anderen Seite schätze ich das Risiko für einen erfolgreichen SSH-Login via Passwörter durchprobieren für sehr gering ein, wenn im Vorfeld gängige security best practices umgesetzt werden, u.a. * Forcieren von Passwortrichtlinien * Automatische Sperrung von Benutzerkonten nach X fehlgeschlagenen Logins Gibt es einen guten Grund seine Linuxserver nicht entsprechend mit PAM und Modulen wie pam_faillock oder pam_tally zu schützen? Grüße, René -- René Xhonneux Dezernat Informationstechnologie (IT) IT-Service Universitätsbibliothek RWTH Aachen University Templergraben 61 52062 Aachen Tel: +49 241 80-94560 Fax: +49 241 80-92273 xhonneux@ub.rwth-aachen.de www.ub.rwth-aachen.de Sprechstunden: Mo. - Fr.: 09:00-15:00 Uhr
Hallo Stephan, grundsätzlich befürworte ich auch Public-Key-Authentifizierung, aber unter Linux z.B. liegt der nicht geschützte Schlüssel dann ja regulär unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein. Vielleicht ist das nur meine Paranoia, aber da hätte ich irgendwie immer ein ungutes Gefühl. Alternativ könnte man vielleicht auch einen Satz Yubikeys für die ganze Einrichtung bestellen und 2FA auf dem Server erzwingen. Danke für den Link zu fail2ban, schaue ich mir mal an. Die Pluggable Authentication Modules haben allerdings den Charme, dass sie auch einen Schutz gegenüber lokalen Angreifern bieten können, deren Verwendung würde ich persönlich unabhängig davon auch immer empfehlen. Grüße, René On Fri, 2020-04-17 at 15:10 +0200, Krinetzki, Stephan wrote:
Hallo René,
aus meiner Sicht ist es eigentlich egal, ob der private Key mit Passwort geschützt ist oder nicht. Da man den Key erstmal haben muss. Und solange der Key nicht irgendwo verteilt wird oder "mitgenommen" wird, ist das deutlich sicherer als mit einem Passwort. Natürlich ist auch besser, den Key mit einem Passwort zu sichern, dann hat man ja zwei Hürden: Man muss den private Key haben und muss dazu das Passwort kennen. Aber allein in den Besitz eines solchen Keys zu kommen sollte nicht ganz einfach sein.
Ich persönliche sichere meinen privaten Server noch mit fail2ban [0] ab. Da beobachte ich das SSH Log und sehe, wer sich dort versucht wie anzumelden. Sollten zu viele Login Versuche passieren, so wird die entsprechende IP für 2h per iptables gebannt. So kann man auch recht gut einem gezielten Angriff entgegen wirken. Die Anzahl der Versuche und Sperrdauer ist dabei leicht anzupassen, würde mit kurzen Zeiten anfangen und das dann irgendwann verlängern. Man kann auch, wie ich es gemacht habe, mit zwei Jails arbeiten: Einem kurzen und bei wiederholten Verstößen, einen langen Jail. Im kurzen sind es wenige Stunden, im langen 2 Tage sperre.
Gruß
Stephan
[0] https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_abs...
-- Stephan Krinetzki
IT Center Gruppe: Systemgruppe Linux Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki@itc.rwth-aachen.de www.itc.rwth-aachen.de
-----Original Message----- From: Xhonneux, René <xhonneux@ub.rwth-aachen.de> Sent: Friday, April 17, 2020 3:00 PM To: rwth-security@lists.rwth-aachen.de Subject: [rwth-security] Re: Status SSH
Hallo,
meine größte Sorge Public-Key-Authentifizierung auf dem Server zu erzwingen wäre, wie man dann auch alle Anwender dazu erzieht den private key mit einem starken Passwort zu schützen und gegebenenfalls einen SSH-Agent zu verwenden.
Andernfalls ist der private key IMHO nur so vertrauenswürdig wie der Rechner, auf dem er genutzt wird und wenn die Prämisse schon "Public- Key-Authentifizierung weil unsichere Passwörter" ist ...
Verlagere ich das Problem damit nicht nur? Wie wird so etwas in anderen Einrichtungen / Instituten gehandhabt?
Auf der anderen Seite schätze ich das Risiko für einen erfolgreichen SSH-Login via Passwörter durchprobieren für sehr gering ein, wenn im Vorfeld gängige security best practices umgesetzt werden, u.a.
* Forcieren von Passwortrichtlinien * Automatische Sperrung von Benutzerkonten nach X fehlgeschlagenen Logins
Gibt es einen guten Grund seine Linuxserver nicht entsprechend mit PAM und Modulen wie pam_faillock oder pam_tally zu schützen?
Grüße, René
-- René Xhonneux Dezernat Informationstechnologie (IT) IT-Service
Universitätsbibliothek RWTH Aachen University Templergraben 61 52062 Aachen Tel: +49 241 80-94560 Fax: +49 241 80-92273 xhonneux@ub.rwth-aachen.de www.ub.rwth-aachen.de
Sprechstunden: Mo. - Fr.: 09:00-15:00 Uhr
Moin, On Fri, Apr 17, 2020 at 01:35:47PM +0000, Xhonneux, René wrote:
unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein.
Was mich auf eine neue Frage bringt: Kennt jemand eine gute Lösung zum Blacklisten von SSH-Keys? Damit man, falls der Key geklaut wurde (oder man das vermutet), möglichst schnell auf möglichst vielen Rechnern diesen Key sperren kann. Ich denke an irgendeine Art von Revocation-List, die man leicht auch über mehrere Rechner hinweg ausrollen kann. Es gibt für die sshd_config die Konfigurationsoption RevokedKeys, die aber einfach auf eine Datei verweist. Damit ist das Verteilungsproblem noch nicht gelöst. Könnte man natürlich auch wieder irgendwie automatisieren, aber wenn man dafür basteln muss, macht das keiner, und wenn man was falsch macht, sperrt man sich aus. Ohne jetzt lange über Details und mögliche Angriffsszenarien nachgedacht zu haben, stelle ich mir sowas vor wie die SSHFP-Einträge im DNS für HostKeys. Grüße, Jan
Wir haben an den Linux-Systemen, die nicht so embedded sind, LDAP. Damit kann man die Auth zentralisieren und zum Beispiel nur da die SSH-Keys ablegen, die sind dann schnell gelöscht. Aber das ist auf so Geräte wo man schlecht automatisieren kann, auch meist nicht möglich.
Moin,
On Fri, Apr 17, 2020 at 01:35:47PM +0000, Xhonneux, René wrote:
unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein. Was mich auf eine neue Frage bringt: Kennt jemand eine gute Lösung zum Blacklisten von SSH-Keys? Damit man, falls der Key geklaut wurde (oder man das vermutet), möglichst schnell auf möglichst vielen Rechnern diesen Key sperren kann.
Ich denke an irgendeine Art von Revocation-List, die man leicht auch über mehrere Rechner hinweg ausrollen kann.
Hallo zusammen, wollte mich (wenn auch recht spät) nochmals an diese gute Diskussion beteiligen. Sofern ich jetzt nichts überlesen habe, ist hier die Rede von - auth mit key - auth mit passwd - 2FA - SSHFP im DNS Hat hier schon jemand über ssh certificates nachgedacht bzw. diese in Verwendung (siehe dazu u.a. [0] - [3])? Diese machen zwar bspw. 2FA und SSHFP (inkl. DNSSEC!) nicht obsolet, erleichtern aber doch das Management bspw. revoke - obwohl ein separater Rechner (vor allem nicht weltwweit per SSH erreichbar) macht aber hier schon Sinn ;) Ich selber habe das leider noch nicht getestet, um Aussagen zu treffen. VG Bernd [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/htm... [1] https://smallstep.com/blog/use-ssh-certificates/ [2] https://medium.com/tarkalabs/ssh-recipes-in-go-an-interlude-6fa88a03d458 [3] https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/ -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler@itc.rwth-aachen.de www.itc.rwth-aachen.de
Moinmoin zusammen, wie stehen hier kurz vor der Benutzung von SSH-Zertifikaten, zumindest für Admins. Grundsätzlich ist das Vorgehen bei Verwendung von öffentlichen Schlüsseln und Zertifikaten fast gleich. Nur erhält ein Benutzer zu seinem öffentlichen Schlüssel zusätzlich ein Zertifikat mit darin enthaltenen "Prinzipalnamen". Das sind Namen, mit denen er sich dann an Maschinen anmelden kann. Die entsprechenden Accounts müssen lokal oder in einem angebundenen Verzeichnis für die jeweilige Maschine existieren. Der Hauptgrund für die Benutzung von Zertifikaten ist die vereinfachte automatische Erzeugung/Änderung und Verteilung der nötigen Dateien. Während man sonst halt Listen mit kompletten Key-Zeilen verteilen muß, reichen bei Zertifikaten Listen mit Benutzernamen (o.a.), was weniger fehlerträchtig ist. In größeren Umgebungen kommt man da nicht um ein Konfigurations-Management-Programm herum. Wir haben hier Cfengine für Unix/Linux-Hosts, das auch den Vorteil hat, daß es über einen eigenen Port und TLS Dateien verteilt. Damit kann man also auch mal sshd_config's verteilen, die einen dann aussperren. :-| Es gibt aber auch überdenkenswerte Nachteile bei Zertifikaten. Ich hab's noch nicht komplett getestet, aber evtl. kann man mit Zertifikaten keine X-Umleitung auf Windows-Clients hinkriegen. Ohne X-Umleitung funktionieren Zertifikate aber z.B. auch mit dem neuen nativen Openssh auf Windows. Ein weiteres Problem oder Feature ist, daß man für einen Benutzer, dem man veränderte Zugriffsrechte im Sinn von Prinzipalen/Rollen erteilen will, immer ein neues Zertifikat er- und bereitstellen muß. Grüße Jochem _____________________________________________________________ Jochem Ippers Institut für Kraftfahrzeuge - RWTH Aachen University EDV, Netzwerk / IT-Department Steinbachstr. 7 - 52074 Aachen - Germany Tel +49 241 80 25628 - Fax +49 241 80 22147 ippers@ika.rwth-aachen.de www.ika.rwth-aachen.de _____________________________________________________________ ________________________________________ Von: Bernd Kohler <kohler@itc.rwth-aachen.de> Gesendet: Dienstag, 21. April 2020 14:19 An: rwth-security@lists.rwth-aachen.de Betreff: [rwth-security] Re: SSH-Key-Revocation? (Re: Re: Status SSH) Hallo zusammen, wollte mich (wenn auch recht spät) nochmals an diese gute Diskussion beteiligen. Sofern ich jetzt nichts überlesen habe, ist hier die Rede von - auth mit key - auth mit passwd - 2FA - SSHFP im DNS Hat hier schon jemand über ssh certificates nachgedacht bzw. diese in Verwendung (siehe dazu u.a. [0] - [3])? Diese machen zwar bspw. 2FA und SSHFP (inkl. DNSSEC!) nicht obsolet, erleichtern aber doch das Management bspw. revoke - obwohl ein separater Rechner (vor allem nicht weltwweit per SSH erreichbar) macht aber hier schon Sinn ;) Ich selber habe das leider noch nicht getestet, um Aussagen zu treffen. VG Bernd [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/htm... [1] https://smallstep.com/blog/use-ssh-certificates/ [2] https://medium.com/tarkalabs/ssh-recipes-in-go-an-interlude-6fa88a03d458 [3] https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/ -- Bernd Kohler IT Center Abteilung: Netze RWTH Aachen University Wendlingweg 10 52074 Aachen Tel: +49 241 80-29793 Fax: +49 241 80-22666 kohler@itc.rwth-aachen.de www.itc.rwth-aachen.de
Anfang des Monats wurde dieser Blogpost [0] veröffentlicht, der die Nutzung von SSH-Zertifikaten anstelle von SSH-Keys vorschlägt. Eine passende Diskussion auf Hacker News [1] gab es natürlich auch. [0] https://gravitational.com/blog/how-to-ssh-properly/ [1] https://news.ycombinator.com/item?id=22750850 On Fri, 17 Apr 2020 at 16:20, Jan Niehusmann <jan@hitnet.rwth-aachen.de> wrote:
Moin,
On Fri, Apr 17, 2020 at 01:35:47PM +0000, Xhonneux, René wrote:
unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein.
Was mich auf eine neue Frage bringt: Kennt jemand eine gute Lösung zum Blacklisten von SSH-Keys? Damit man, falls der Key geklaut wurde (oder man das vermutet), möglichst schnell auf möglichst vielen Rechnern diesen Key sperren kann.
Ich denke an irgendeine Art von Revocation-List, die man leicht auch über mehrere Rechner hinweg ausrollen kann.
Es gibt für die sshd_config die Konfigurationsoption RevokedKeys, die aber einfach auf eine Datei verweist. Damit ist das Verteilungsproblem noch nicht gelöst. Könnte man natürlich auch wieder irgendwie automatisieren, aber wenn man dafür basteln muss, macht das keiner, und wenn man was falsch macht, sperrt man sich aus.
Ohne jetzt lange über Details und mögliche Angriffsszenarien nachgedacht zu haben, stelle ich mir sowas vor wie die SSHFP-Einträge im DNS für HostKeys.
Grüße, Jan _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Alternativ könnte man vielleicht auch einen Satz Yubikeys für die ganze Einrichtung bestellen und 2FA auf dem Server erzwingen.
OpenSSH unterstützt seit Version 8.2 FIDO2 nativ. Dann liegt dein Key entweder immer verschlüsselt auf dem Rechner (oder dem Authenticator, Stichwort "resident keys") und wird beim Verbinden durch den Authenticator entschlüsselt. Wenn der Authenticator noch eine PIN abfragt, hast du sogar zwei Faktoren und der Authenticator kann nicht von jedem verwendet werden. Nachteil: da der Private-Key nie unverschlüsselt den Authenticator verlässt, dürften Agents nicht funktionieren. On Fri, 17 Apr 2020 at 15:36, Xhonneux, René <xhonneux@ub.rwth-aachen.de> wrote:
Hallo Stephan,
grundsätzlich befürworte ich auch Public-Key-Authentifizierung, aber unter Linux z.B. liegt der nicht geschützte Schlüssel dann ja regulär unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein.
Vielleicht ist das nur meine Paranoia, aber da hätte ich irgendwie immer ein ungutes Gefühl. Alternativ könnte man vielleicht auch einen Satz Yubikeys für die ganze Einrichtung bestellen und 2FA auf dem Server erzwingen.
Danke für den Link zu fail2ban, schaue ich mir mal an. Die Pluggable Authentication Modules haben allerdings den Charme, dass sie auch einen Schutz gegenüber lokalen Angreifern bieten können, deren Verwendung würde ich persönlich unabhängig davon auch immer empfehlen.
Grüße, René
On Fri, 2020-04-17 at 15:10 +0200, Krinetzki, Stephan wrote:
Hallo René,
aus meiner Sicht ist es eigentlich egal, ob der private Key mit Passwort geschützt ist oder nicht. Da man den Key erstmal haben muss. Und solange der Key nicht irgendwo verteilt wird oder "mitgenommen" wird, ist das deutlich sicherer als mit einem Passwort. Natürlich ist auch besser, den Key mit einem Passwort zu sichern, dann hat man ja zwei Hürden: Man muss den private Key haben und muss dazu das Passwort kennen. Aber allein in den Besitz eines solchen Keys zu kommen sollte nicht ganz einfach sein.
Ich persönliche sichere meinen privaten Server noch mit fail2ban [0] ab. Da beobachte ich das SSH Log und sehe, wer sich dort versucht wie anzumelden. Sollten zu viele Login Versuche passieren, so wird die entsprechende IP für 2h per iptables gebannt. So kann man auch recht gut einem gezielten Angriff entgegen wirken. Die Anzahl der Versuche und Sperrdauer ist dabei leicht anzupassen, würde mit kurzen Zeiten anfangen und das dann irgendwann verlängern. Man kann auch, wie ich es gemacht habe, mit zwei Jails arbeiten: Einem kurzen und bei wiederholten Verstößen, einen langen Jail. Im kurzen sind es wenige Stunden, im langen 2 Tage sperre.
Gruß
Stephan
[0]
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_abs...
-- Stephan Krinetzki
IT Center Gruppe: Systemgruppe Linux Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki@itc.rwth-aachen.de www.itc.rwth-aachen.de
-----Original Message----- From: Xhonneux, René <xhonneux@ub.rwth-aachen.de> Sent: Friday, April 17, 2020 3:00 PM To: rwth-security@lists.rwth-aachen.de Subject: [rwth-security] Re: Status SSH
Hallo,
meine größte Sorge Public-Key-Authentifizierung auf dem Server zu erzwingen wäre, wie man dann auch alle Anwender dazu erzieht den private key mit einem starken Passwort zu schützen und gegebenenfalls einen SSH-Agent zu verwenden.
Andernfalls ist der private key IMHO nur so vertrauenswürdig wie der Rechner, auf dem er genutzt wird und wenn die Prämisse schon "Public- Key-Authentifizierung weil unsichere Passwörter" ist ...
Verlagere ich das Problem damit nicht nur? Wie wird so etwas in anderen Einrichtungen / Instituten gehandhabt?
Auf der anderen Seite schätze ich das Risiko für einen erfolgreichen SSH-Login via Passwörter durchprobieren für sehr gering ein, wenn im Vorfeld gängige security best practices umgesetzt werden, u.a.
* Forcieren von Passwortrichtlinien * Automatische Sperrung von Benutzerkonten nach X fehlgeschlagenen Logins
Gibt es einen guten Grund seine Linuxserver nicht entsprechend mit PAM und Modulen wie pam_faillock oder pam_tally zu schützen?
Grüße, René
-- René Xhonneux Dezernat Informationstechnologie (IT) IT-Service
Universitätsbibliothek RWTH Aachen University Templergraben 61 52062 Aachen Tel: +49 241 80-94560 Fax: +49 241 80-92273 xhonneux@ub.rwth-aachen.de www.ub.rwth-aachen.de
Sprechstunden: Mo. - Fr.: 09:00-15:00 Uhr
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Thomas Vogt <thomas.vogt1@rwth-aachen.de> writes:
Und IPsec, was man eigentlich schön (sprich IKEv2) machen könnte, kann ja Cisco leider nicht (oder das RZ wirft nicht genug Münzen ein). Vor ein paar Monaten ging IPSec mit NetworkManager und Android noch. Liegt das dann wirklich an Cisco?
Na, es geht schon. Ist aber halt XAuth, und das hat bekannte massive Sicherheitslücken. -- Fachschaft I/1 Mathematik/Physik/Informatik der RWTH Aachen Thomas Schneider Campus Mitte: Augustinerbach 2a, 52062 Aachen Telefon: +49 241 80 94506 Informatikzentrum: Ahornstraße 55, Raum 2014, 52074 Aachen Telefon: +49 241 80 26741 https://www.fsmpi.rwth-aachen.de
Unter macOS, iOS und iPadOS funktioniert es jedenfalls nicht mehr. Würde es aber auch begrüßen, wenn nicht mehr so viel auf VPNs vertraut und mehr auf Zero-Trust-Security gesetzt werden würde. Auf die Integrität eines (so großen) Netzwerks zu vertrauen halte ich für den falschen Ansatz. Das vermittelt ein falsches Gefühl von Sicherheit. On Fri, 17 Apr 2020 at 15:20, Thomas Vogt <thomas.vogt1@rwth-aachen.de> wrote:
Und IPsec, was man eigentlich schön (sprich IKEv2) machen könnte, kann ja Cisco leider nicht (oder das RZ wirft nicht genug Münzen ein). Vor ein paar Monaten ging IPSec mit NetworkManager und Android noch. Liegt das dann wirklich an Cisco?
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Hallo zusammen, ob es hier richtig bin oder ich wieder alles Falsch mache weiß ich nicht! Aber ich wusste gerne, warum nicht ein Eintag in dem Firewall-Formular (https://noc-portal.rz.rwth-aachen.de/firewall-formular/service_activations/n...) so wie die neue Seite es RWTH-Firewall-Monitor (https://noc-portal.rz.rwth-aachen.de/firewall-view2/overview) folgende anträge anzeigt. (Belgium Germany Luxembourg Netherlands any Europe United States oder Germany Austria Switzerland Norway cartesius.info. oder any) Also eine Select Box existiert schon in dem Firewall-Formular nur nicht die Einträge! Vielleicht, wenn diese Existieren, würden die Leute sich fragen, welche Einschränkung machte ich haben. Da nicht alle diesen Mail Verteiler bekommen und auch nicht Unbedingt alles mitbekommen, was das ITC so tolles kann oder zu Verfügung stellt. Ist doch Einfacher, da ich zum Beispiel nicht wusste, dass das ITC das auch machen kann! Zum SSH Verbindung, finde ich Persönlich besser als ein extra Programm zu Installieren. Da ssh-Client hat jetzt auch Windows und es wird von Windows gewartet. Wenn man dann gerne eine Grafik haben möchte, der kann sich auch mit X2go eine Grafik Verbindung aufbauen über ssh. Vermutlich wird der Explora von Windows auch bald sftp/ssh Verbindungen machen können. Mit der Sicherheit, ist sowieso eine Frage! VPN kann auch gehackt werden oder Probleme machen, so wie auch bei einem ssh Dienst. Nur meine Ansicht nach! Wenn ihr Verbesserungen habe, lasst es gerne zu kommen! Mit freundlichen Grüßen, Benedikt Meier RWTH Aachen University Operations Research Kackertstr. 7, 2.OG, Raum B253 52072 Aachen Tel.: +49 241 80 93381 Web: https://www.or.rwth-aachen.de On 17/04/2020 12:24, Jens Hektor wrote:
Hier mal eine Zusammenfassung bzgl. der Angriffe via SSH.
SSH ist mit 809 weltweit freigeschalteten IP-Adressen nach HTTPS (1333) und HTTP (1122) auf Platz drei der Freischaltungsrangliste in der RWTH-Firewall. Dazu kommen noch 60 Server auf anderen Ports bzw. mit reduzierten (auf DE+BeNeLux) Freischaltungen.
Teilweise werden diese Freischaltungen in nachgelagerten ACLs auf den Routern reduziert.
* Wünschenswert wäre hier sicherlich mehr Server in der DE+BeNeLux Gruppe zu haben, als diese weltweit zu exponieren. *
Bei den gescannten Diensten ist SSH (wie auch RDP) eigentlich immer in den Top10, Top ist hier (mit Abstand) Telnet, gefolgt von HTTP.
Quellen der Scans sind zu großen Teilen Würmer auf Geräten der Klasse IoT, also Home-Router, IP-Kameras, Video-Abspieler und SAT-Empfänger, usw. Diese versuchen dann per Brute-Force weitere Geräte zu finden, meist mit Standard Credentials. Eine besondere Rolle spielen hierbei ältere Raspberry PI, da diese meist mit Defaultpassworten betrieben wurden.
Wir hatten in den letzten 3 Jahren vier Zwischenfälle mit SSH, die im wesentlichen 2 Ursachen hatten:
a) leichtsinnig gesetztes simples Passwort b) kein Bewusstsein dafür, dass diese IP weltweit erreichbar ist
Auf dem Logserver checkpoint.rz filtern wir SSH bezogene Logs in eine Datei rein, hier mal so eine Grobauswertung der 280K Zeilen aus diesen Logs (April 2020):
Management System NOC: 50K Security Scanner: 22K Monitoring RZ-Cluster: 14K Cisco-ACLs IPv4: 49K Failed Password: 59K Refused Connect (Wrapper): 75K Invalid User: 9K Management Institut: 3K Cisco-ACLs IPv6: 1K RWTH-Firewall: 1K
(gibt in der Summe Rundungsfehler)
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
participants (15)
-
Benedikt Meier -
Bernd Kohler -
Ehlenz, Matthias -
Florian Kerber -
Frank Knoben -
Ippers, Jochem -
Jan Niehusmann -
Jens Hektor -
Julius Rickert -
Krinetzki, Stephan -
Markus Witt -
Prieler, Robert -
Thomas Schneider -
Thomas Vogt -
Xhonneux, René