Zero-Day-Exploit für SSH-Server - Vorschläge, um uns zu schützen

Laut dem Internet Storm Center scheint es einen Zero-Day-Exploit für SSH zu geben.

Hier finden Sie einige Beweise für das Konzept und Verweise:

• http://secer.org/hacktools/0day-openssh-remote-exploit.html
• http://isc.sans.org/diary.html?storyid=6742

Dies scheint ein ernstes Problem zu sein, daher sollte jeder Linux / Unix-Systemadministrator vorsichtig sein.

Wie schützen wir uns, wenn dieses Problem nicht rechtzeitig behoben wird? Oder wie gehen Sie mit Zero-Day-Exploits im Allgemeinen um?

* Ich werde meinen Vorschlag in den Antworten veröffentlichen.

Kommentar von Damien Miller (OpenSSH-Entwickler): http://lwn.net/Articles/340483/

Insbesondere habe ich einige Zeit damit verbracht, eine von ihm bereitgestellte Paketverfolgung zu analysieren, aber es scheint sich um einfache Brute-Force-Angriffe zu handeln.

Ich verfolge also nicht, dass überhaupt ein 0-Tag existiert. Der einzige Beweis bisher sind einige anonyme Gerüchte und nicht überprüfbare Aufschaltungsprotokolle.

Mein Vorschlag ist, den SSH-Zugriff auf die Firewall für alle anderen außer Ihrer IP-Adresse zu blockieren. Auf Iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

Laut so der SANS-Post ist dieser Exploit does not work against current versions of SSHund somit eigentlich kein 0Tag. Patchen Sie Ihre Server, und es sollte Ihnen gut gehen.

Beschweren Sie sich bei Ihren Lieferanten

Auf diese Weise erhält jeder die neuere Version.

Zur Info, die ursprüngliche Quelle der Geschichte: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Es gibt auch zwei ähnliche Geschichten (Hacken von astalavista.com und einer anderen Site): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Es scheint, als hätte jemand eine Agenda: romeo.copyandpaste.info/ ("0 Tage privat halten")

Ich kompiliere SSH, um tcprules zu verwenden, und habe eine kleine Anzahl von Zulassungsregeln, die alle anderen ablehnen.

Dies stellt auch sicher, dass Passwortversuche nahezu ausgeschlossen sind und dass ich Berichte über Abbruchversuche ernst nehmen kann, wenn sie gesendet werden.

Ich lasse ssh nicht auf Port 22 laufen. Da ich mich oft von verschiedenen Rechnern aus anmelde, mag ich es nicht, den Zugriff über iptables zu verhindern .

Dies ist ein guter Schutz vor Zero-Day-Angriffen, die mit Sicherheit der Standardkonfiguration entsprechen. Es ist weniger effektiv gegen jemanden, der versucht, nur meinen Server zu kompromittieren. Ein Port-Scan zeigt an, auf welchem ​​Port ich ssh ausführe, aber ein Skript, das zufällige SSH-Ports angreift, überspringt meine Hosts.

Um Ihren Port zu ändern, fügen Sie einfach den Port in Ihrer / etc / ssh / sshd_config- Datei hinzu bzw. ändern ihn .

Ich würde Firewall und warten. Mein Bauchgefühl ist eines von zwei Dingen:

A> Hoax. Nach den wenigen und fehlenden Informationen, die bisher gegeben wurden, ist es entweder das ..

oder...

B> Dies ist ein "Rauch- und Täuschungsversuch", der Besorgnis über 4.3 hervorrufen soll. Warum? Was ist, wenn Sie, eine Hacker-Organisation, in sshd 5.2 einen wirklich coolen Zero-Day-Exploit finden?

Schade, dass nur die neuesten Versionen (Fedora) diese Version enthalten. Keine wesentlichen Einheiten verwenden dies in der Produktion. Viel Gebrauch RHEL / CentOS. Große Ziele. Es ist bekannt, dass RHEL / CentOS alle ihre Sicherheits-Fixes zurückportieren, um eine Art grundlegende Versionskontrolle beizubehalten. Die Teams dahinter sind nicht zu verachten. RHEL hat veröffentlicht (ich habe gelesen, ich müsste den Link ausgraben), dass sie alle Versuche, einen Fehler in 4.3 zu finden, ausgeschöpft haben. Worte, die man nicht leicht nehmen sollte.

Also zurück zur Idee. Ein Hacker beschließt, auf irgendeine Weise eine Aufregung um 4,3 zu verursachen, was eine Massenhysterie von UG bis 5,2 p1 verursacht. Ich frage: wie viele von euch haben schon?

Um einen "Beweis" für eine Fehlleitung zu erstellen, müsste die "besagte Gruppe" lediglich ein zuvor kompromittiertes System ( WHMCS ? Vorheriges SSH?) Übernehmen , einige Protokolle mit einigen Halbwahrheiten erstellen (Angriff-ee bestätigte "etwas"). passiert ist, doch einige Dinge sind vom Ziel nicht überprüfbar) in der Hoffnung, jemand würde "beißen". Alles was es braucht ist eine größere Einheit, um etwas drastisches (... HostGator ...) zu tun, um es ein bisschen ernster zu machen, inmitten der wachsenden Besorgnis und Verwirrung.

Viele große Entitäten können einen Backport ausführen, einige können jedoch nur ein Upgrade durchführen. Diejenigen, die ein Upgrade durchführen, sind jetzt offen für echte Zero-Day-Angriffe, die noch nicht veröffentlicht wurden.

Ich habe gesehen, wie seltsame Dinge passiert sind. Wie ein Haufen Prominenter, die alle in einer Reihe sterben ...

Zu Telnet wechseln? :)

Spaß beiseite, wenn Sie Ihre Firewall richtig konfiguriert haben, erlaubt sie bereits SSH-Zugriff auf einige wenige Hosts. Sie sind also in Sicherheit.

Eine schnelle Lösung könnte darin bestehen, SSH von der Quelle zu installieren (es von openssh.org herunterzuladen), anstatt alte Versionen zu verwenden, die auf den neuesten Linux-Distributionen vorhanden sind.