Exploitation zero-day du serveur SSH - Suggestions pour nous protéger

13

Selon Internet Storm Center , il semble y avoir un exploit de jour zéro SSH.

Il y a du code de preuve de concept ici et des références:

Cela semble être un problème sérieux, donc tout administrateur système Linux / Unix doit être prudent.

Comment pouvons-nous nous protéger si ce problème n'est pas corrigé à temps? Ou comment gérez-vous les exploits zero-day en général?

* Je posterai ma suggestion dans les réponses.

— sucuri
source

Est-ce réel? Un petit googletrolling a révélé que seclists.org/fulldisclosure/2009/Jul/0028.html était la source la plus originale de cette rumeur. Quelqu'un a-t-il une vérification indépendante de cela?

— chris

Beaucoup de bons commentaires sur Hacker News à propos de ce problème: news.ycombinator.com/item?id=692036

— sucuri

6

Commentaire de Damien Miller (développeur OpenSSH): http://lwn.net/Articles/340483/

En particulier, j'ai passé un certain temps à analyser une trace de paquet qu'il a fournie, mais elle semble consister en de simples attaques par force brute.

Donc, je ne suis pas du tout convaincu qu'il existe un jour 0. Les seules preuves à ce jour sont des rumeurs anonymes et des transcriptions d'intrusions invérifiables.

— x-way
source

Je pense que nous pouvons prendre sa parole pour l'instant ...

— sucuri

11

Ma suggestion est de bloquer l'accès SSH sur le pare-feu à tout le monde en plus de votre IP. Sur iptables:

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

— sucuri
source

5

Selon le poste SANS, cet exploit does not work against current versions of SSH, et n'est donc pas vraiment un 0day. Patchez vos serveurs et tout ira bien.

— Dentrasi
source

2

techniquement, c'est un exploit de 0 jour (non publié et inconnu) mais qui ne fonctionne que sur les anciennes versions de SSH. Cependant, la version par défaut sur RHEL, Fedora sont vulnérables (selon le deuxième post). Donc, c'est un gros problème s'il n'y a pas de patch de votre distribution (à moins que vous n'utilisiez ssh à partir d'une source qui n'est pas courante) ...

— sucuri

1

Ils spéculent sur la base des journaux d'attaque. Personne ne sait avec certitude ... Même la dernière version pourrait être vulnérable

— sucuri

3

Se plaindre à vos fournisseurs

De cette façon, tout le monde obtient la nouvelle version.

— Brad Gilbert
source

3

Pour info, la source originale de l'histoire: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Il existe également deux histoires similaires (piratage astalavista.com et un autre site): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Il semble que quelqu'un ait un agenda: romeo.copyandpaste.info/ ("Gardez 0 jours privé")

— x-way
source

D'accord. Le groupe derrière les journaux d'origine qui a commencé cela a un énoncé de mission pour jouer avec "l'industrie de la sécurité" - et quelle meilleure façon de le faire que de mettre tout le monde en colère contre "omg! Openssh 0day?! Comment le trouver / arrêter ça / hack avec ça? "

— cji

Ce ne serait pas la première fois que de telles rumeurs et battage médiatique se révéleraient faux non plus.

— Dan Carley

2

Je compile SSH pour utiliser tcprules, et j'ai un petit nombre de règles d'autorisation, en refusant toutes les autres.

Cela garantit également que les tentatives de mot de passe sont presque éliminées et que lorsque je reçois des rapports sur les tentatives d'effraction, je peux les prendre au sérieux.

— Ernie
source

2

Je n'exécute pas ssh sur le port 22. Comme je me connecte souvent à partir de différentes machines, je n'aime pas empêcher l'accès via iptables .

C'est une bonne protection contre attaques zero-day - qui iront sûrement après la configuration par défaut. C'est moins efficace contre quelqu'un qui essaie de compromettre juste mon serveur. Une analyse de port montrera sur quel port j'utilise ssh, mais un script attaquant des ports SSH aléatoires ignorera mes hôtes.

Pour changer votre port, ajoutez / modifiez simplement le port dans votre fichier / etc / ssh / sshd_config .

— brianegge
source

L'exécution de SSH sur un port non standard semble réduire le nombre d'attaques par force brute auxquelles il est soumis et vous protégera probablement de la plupart des vers. Ce n'est pas une défense contre quelqu'un qui scanne manuellement les choses, et un ver pourrait à l'avenir simplement scanner tous les ports à la recherche de ssh (ce qui est facile, prend beaucoup de temps)

— MarkR

@MarkR: Cela ne peut pas arrêter un «cracker / kiddie / hacker» déterminé, mais il gardera les bots à distance jusqu'à ce qu'un correctif soit publié. C'est à mon humble avis le plus important.

— Andrioid

2

Je voudrais pare-feu et attendre. Mon instinct est l'une des deux choses:

A> canular. Par le peu d'informations manquantes fournies jusqu'ici, c'est soit ceci ..

ou...

B> Il s'agit d'une tentative de «fumée et tromperie», pour inquiéter 4.3. Pourquoi? Et si vous, une organisation de hackers, trouviez un exploit zero-day vraiment cool dans sshd 5.2.

Dommage que seules les versions de pointe (Fedora) intègrent cette version. Aucune entité importante ne l'utilise dans la production. Beaucoup utilisent RHEL / CentOS. De grandes cibles. Il est bien connu que RHEL / CentOS rétroporte tous leurs correctifs de sécurité pour conserver une sorte de contrôle de version de base. Les équipes derrière cela ne doivent pas être éternuées. RHEL a posté (j'ai lu, devrait creuser le lien) qu'ils ont épuisé toutes les tentatives pour trouver un défaut dans 4.3. Les mots à ne pas prendre à la légère.

Donc, revenons à l'idée. Un pirate informatique décide de provoquer une agitation d'environ 4,3, provoquant une hystérie de masse à UG à 5,2p1. Je demande: combien d'entre vous en avez déjà?

Pour créer une "preuve" pour une mauvaise direction, tout ce que le "groupe" devrait faire maintenant est de reprendre un système précédemment compromis ( WHMCS ? SSH précédent?), De créer des journaux avec des demi-vérités (attack-ee a vérifié "quelque chose") arrivé, mais certaines choses invérifiables par cible) en espérant que quelqu'un "mordrait". Tout ce qu'il faut, c'est une entité plus grande pour faire quelque chose de drastique (... HostGator ...) pour le rendre un peu plus sérieux, au milieu de l'angoisse croissante et de la confusion.

De nombreuses grandes entités peuvent rétroporter, mais certaines peuvent simplement se mettre à niveau. Ceux qui évoluent, sont désormais ouverts à la véritable attaque zero-day sans aucune divulgation pour l'instant.

J'ai vu des choses plus étranges se produire. Comme, un tas de célébrités mourant toutes de suite ...

— Peter Mortensen
source

0

Passer à Telnet? :)

Blague à part, si votre pare-feu est correctement configuré, il n'autorise déjà l'accès SSH qu'à quelques hôtes. Vous êtes donc en sécurité.

Une solution rapide pourrait être d'installer SSH à partir de la source (en le téléchargeant depuis openssh.org), au lieu d'utiliser les anciennes versions présentes sur les dernières distributions Linux.

— sucuri
source

Telnet Kerberized est en fait raisonnablement sûr. La bonne chose à propos de kerberos est que vous pouvez révoquer une clé de manière centralisée si vous le souhaitez, contrairement à ssh où vous devez visiter chaque hôte et supprimer une clé de chaque fichier authorized_keys.

— chris