Bonjour,
Ce n'est encore qu'une rumeur, mais tout le monde s'affole.
Au cas ou se serait sérieux et confirmé, autant commencer à s'y intéresser.
Pour moi, les premières infos viennent d'ici : [http://isc.sans.org/diary.html?storyid=6742]
Ce que je sais pour le moment :
Chez mon hébergeur (OVH) ils prennent leurs précautions :
leur ancienne distrib interne qui tourne encore chez beaucoup de clients (OVH release 1, basé sur redhat 7.2) avait OpenSSH 4.x
Ils sont en train de tout patcher pour passer en 5.2.
C'est préventif, on ne sais pas trop si le fait de passer de 4.x en 5.x peut éviter la supposée faille, mais c'est toujours mieux d'être à jour.
Sur une mailing-liste OVH, un des clients pense qu'il s'est déjà fait hacké un serveur, mais n'a rien pour le prouver.
J'ouvre donc ce journal pour :
- vous informer qu'il faut suivre un minimum (au cas ou... être prêt)
- proposer de regrouper en commentaire toute information complémentaire qu'on trouverait
Pour infos sur Debian :
En Debian Lenny on est en version : openssh_5.1p1-5 ( http://packages.debian.org/fr/lenny/openssh-server )
Attention en Debian etch c'est encore openssh_4.3p2-9etch3 ( http://packages.debian.org/fr/etch/openssh-server )
Les conseils :
- un fail2ban ne suffirait pas puisque l'attaque n'est pas un brute-force
- il est bien de changer le port par défaut de SSH puisqu'il semble qu'il y ait une augmentation statistique des scans pour vérifier l'ouverture de ce port 22
- suivre l'actu.....
Bonne soirée à tous,
Julien
# Et si....
Posté par Ph Husson (site web personnel) . Évalué à 10.
[^] # Re: Et si....
Posté par Julien04 (site web personnel) . Évalué à 3.
Mais dans le cas présent, un autre commentaire pointe sur cette histoire commentée :
[ttp://www.tux-planet.fr/astalavista-pwnage-expose-by-anti-sec-group/]
A priori la cible était un OpenSSH_4.3 si je comprend bien.
ça ne dit pas que la 5.x n'est pas touchée, mais ça prouverait que la 4.3 l'est...
[^] # Re: Et si....
Posté par fcartegnie . Évalué à 5.
http://secer.org/hacktools/0day-openssh-remote-exploit.html
[^] # Re: Et si....
Posté par briaeros007 . Évalué à 2.
[^] # Re: Et si....
Posté par Sébastien B. . Évalué à 3.
(bon, c'est certainement faux, mais je trouverais ça marrant)
[^] # Re: Et si....
Posté par Zakath (site web personnel) . Évalué à 7.
[^] # Re: Et si....
Posté par Sébastien B. . Évalué à 2.
[^] # Re: Et si....
Posté par Maclag . Évalué à 3.
Bon, je vais de ce pas recopier le second!
-------------> [ ]
# Knockd
Posté par the_glu . Évalué à 6.
[^] # Re: Knockd
Posté par André Rodier . Évalué à 7.
# humm
Posté par pampryl . Évalué à -1.
=> soupçon et surveillance
+ Ce journal
=> serveur compromis... :-/ (une recherche active des dégâts en perspective)
# Hadopi
Posté par Diagonale de Cantor (site web personnel) . Évalué à 10.
[^] # Re: Hadopi
Posté par Romeo . Évalué à -8.
http://openbsd.org/45.html
-> OpenSSH 5.2
La faille ne semblerait toucher qu'openssh 4.3 fournis avec les derniers redhat et clones.
# Un rapport avec ceci?
Posté par pampryl . Évalué à 3.
(l'attaque : http://www.tux-planet.fr/public/hack/nowayout.txt mais pas assez pour comprendre la faiblesse utilisée...)
[^] # Re: Un rapport avec ceci?
Posté par Julien04 (site web personnel) . Évalué à 2.
[^] # Re: Un rapport avec ceci?
Posté par X345 . Évalué à 5.
[^] # Re: Un rapport avec ceci?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
Où n'est-ce pas une méthode pour faire parler d'eux ?
[^] # Re: Un rapport avec ceci?
Posté par Maclag . Évalué à 10.
[^] # Re: Un rapport avec ceci?
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Un rapport avec ceci?
Posté par pampryl . Évalué à 2.
anti-sec:~/pwn# ./infoz infosec.org.uk
IP: 66.96.220.213
NS:
- ns1.webhostline.com
- ns2.webhostline.com
Mail Server:
- 66.96.220.213 > 6696220213.hostnoc.net
WWW Server:
Apache
SSH Banner:
SSH-2.0-OpenSSH_4.3 : PORT 2222
anti-sec:~/pwn# cd xpl/
anti-sec:~/pwn/xpl# ./openPWN -h 66.96.220.213 -p 2222 -l=users.txt
[+] openPWN - anti-sec group
[+] Target: 66.96.220.213
[+] SSH Port: 2222
[+] List: users.txt
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]
user: crownvip
uname: Linux srv01.webhostline.com 2.6.21.5-hostnoc-3.1.7-libata-grsec-32 #1 SMP Mon Feb 11 06:36:58 EST 2008 i686 i686 i386 GNU/Linux
Manifestement, si le "log" (partiel) est bien celui de l'attaque, c'était bien un apache et c'est sur le port SSH que s'est déroulé l'attaque...
à moins que tu n'es d'autres sources à nous faire partager ;-)
[^] # Re: Un rapport avec ceci?
Posté par TortuXm . Évalué à 2.
* en paramètre de son script, il utilise un fichier users.txt. C'est donc a priori nécessaire d'attaquer avec une liste de noms, je ne vois pas de raison qui proscrive l'utilisation d'une brute force pour rentrer dans OpenSSH.
* Il fait juste après l'entrée sur le serveur un "jail break". Le noyau est patché grsec (cf le uname -a), et il se trouve qu'il a une faille connue donnée en lien plus haut : http://www.digitalarmaments.com/2007200184936274.html. Il n'est pas impossible que ce soit cette faille qui soit utilisée.
On peut trouver des sites qui commencent à parler de hoax à ce sujet : http://isc.sans.org/diary.html?storyid=6760
[^] # Re: Un rapport avec ceci?
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Un rapport avec ceci?
Posté par Boa Treize (site web personnel) . Évalué à 2.
anti-sec:~# ./g0tshell astalavista.com -p 80
[+] Connecting to astalavista.com:80
[+] Grabbing banner...
LiteSpeed
[+] Injecting shellcode...
[-] Wait for it
[~] We g0tshell
uname -a: Linux asta1.astalavistaserver.com 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:35:59 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
ID: uid=100(apache) gid=500(apache) groups=500(apache)
sh-3.2$ cat /etc/passwd
(...)
C'est le serveur web (LiteSpeed) qui a été craqué (il s'exécutait en tant qu'utilisateur nommé « apache » ce qui porte à confusion).
Source : cache Google, car l'original a disparu (comme prévu) : http://209.85.135.132/search?q=cache:mA8d4EnYvj8J:pastebin.c(...)
[^] # Re: Un rapport avec ceci?
Posté par pampryl . Évalué à 2.
Celle que je cite en premier semble bien avoir un lien avec la rumeur qui traîne depuis hier.
# Des infos supp
Posté par Julien04 (site web personnel) . Évalué à 2.
Encore quelques infos [http://www.zataz.com/forum/index.php?autocom=blog&blogid(...)]
A priori ça comporterait un minimum de brute-force, mais sur l'user !
Voici par exemple la liste des users testés sur un serveur de zataz:
[http://www.zataz.net/eromang/invalide-ssh-user-list.txt]
Les classiques comme root ou ROOT, mais également les prénoms très portés comme john y sont présents (julien également ;-) )
[^] # Re: Des infos supp
Posté par polytan . Évalué à 3.
[^] # + d'infos
Posté par viking . Évalué à 10.
In particular, I spent some time analysing a packet trace that he provided, but it seems
to consist of simple brute-force attacks.
So, I'm not pursuaded that an 0day exists at all. The only evidence so
far are some anonymous rumours and unverifiable intrusion transcripts.
[^] # Re: + d'infos
Posté par gaston . Évalué à 6.
# Pas facile de ce prononcer...
Posté par X345 . Évalué à 8.
D'un côté, le seul début de preuve de l'existence d'un tel exploit sont les logs publiés par ceux qui se proclament les auteurs de ceux-ci. Rien de vraiment tangible donc. D'ailleurs la reprise de ce log dans divers sites d'informations concernant la sécurité informatique à un peu tendance à lui donner une importance démesurée. C'est peut-être un gros coup de bluff, je peux rédiger de tels logs dans la demi-heure qui suit. OpenSSH est quand même la cible idéale pour un gros coup de bluff : très utilisé et surtout réputé très sécurisé. Quelqu'un capable de trouver une faille dans OpenSSH est supposé capable d'en trouver une dans une multitude de logiciels. Ce genre d'annonce fait planer le spectre de l'impossibilité de sécuriser quoique ce soit...
D'un autre côté, on note actuellement une augmentation des scans de port SSH en ce moment. Dans la même veine, ça ne veut rien dire non plus. Je peux également faire des tas de scans SSH dans la demi-heure qui suit.
Bref, à mon sens aucun élément de preuve valable, juste des bribes d'infos.
Ce qui permettrait à mon avis d'éclaircir cette rumeur serait que les personnes ayant eu des serveurs compromis le signalent, de ma manière à voir si l'on a une augmentation statistique significative des attaques
[^] # Re: Pas facile de ce prononcer...
Posté par Julien04 (site web personnel) . Évalué à 3.
Je pense avoir été touché sur un SP sur centos.
Mon fail2ban est plutôt chatouilleux (2 erreurs = 1 ban 48h), et
pourtant, il y'a 72 ou 96h , j'ai eu 2 users root qui ont réussi à se
logger depuis des ip roumaines.
Le mot de passe était assez fort, et vu la vitesse des scans, je ne
pense qu'il ait pu le casser. De +, le passe n'est enregistré nul part.
Mon bash_history a été vidé of course....Je ne pense pas qu'ils aient eu
le temps de faire quoique ce soit....
J'ai viré le port 22, et j'ai désactivé le login par password pour du
only RSA (2048 bits cette fois) en attendant de voir ce que ça dit.
Je pense vraiment à une faille car je vois pas comment ils auraient pu
casser le password sinon... :(
Depuis il n'a pas donné d'info supplémentaire sur sa recherche d'information.
[^] # Re: Pas facile de ce prononcer...
Posté par med . Évalué à 4.
[^] # Re: Pas facile de ce prononcer...
Posté par herodiade . Évalué à 10.
Pour relativiser un tel témoignage, il est bon de préciser que les m-l d'OVH sont saturées de bras cassés et autres admins du dimanche... (pas toujours capables de découvrir _comment_ ils se sont fait pirater, par ex.).
Quant au "patch" fournis par OVH (une réaction du type : "la *rumeur* semble vaguement indiquer qu'un problème touches les vielles [sans précisions] versions alors upgradons tout sur la dernière release"), là aussi il convient de connaître cet hébergeur pour ne pas s'affoler prématurément.
OVH est champion de la sécu à la kéké / jacky (on sécurise une distro comme on tune une voiture : en ajoutant des ailerons qui brillent). En témoigne leur distro (un fork de gentoo, ça va de soi) basée sur un kernel patché GRsec, le fameux jeux de patchs dont les mainteneurs du noyau - et les distros commerciales employant des devs noyaux (pas le cas d'ovh à priori...) - ne veulent pas.
Alors les voir "résoudre" au pifomètre ("on upgrade à la dernière release") un problème dont personne ne sait rien (y compris comment le résoudre) ne doit pas vous alarmer, et n'est en aucun cas un signe indiquant que la rumeur serait fondée.
Je crois que la meilleur source d'information à cette heure (la plus crédible) reste l'analyse du mainteneur principal d'OpenSSH. S'il y a un vrai problème, il sera l'un des premiers informés, et probablement l'un des premier à trouver/fournir la solution adaptée :
http://marc.info/?l=openssh-unix-dev&m=124705272824524&a(...)
Concernant la prévention : pour contenir les vrais problèmes courants ou avérés (mots de passes faibles ou "leakés", applis installées ayant crée des users avec mots de passes std/par défaut, certificats/clefs pourries, brute force, mdp saisi sur une machine keylogguée dans un cybercafé polonais, ...), il est utile de restreindre (avec un firewall) l'accès au port 22 aux seules IP utilisées par les admins. Ne pas exposer un tel service à tout l'internet tant que ce n'est pas nécessaire.
[^] # Re: Pas facile de ce prononcer...
Posté par Zenitram (site web personnel) . Évalué à 4.
Eux gèrent >50 000 serveurs sans trop de casse (ils subissent de nombreuses attaques, forcément autant de machines c'est intéressant), qui es-tu pour penser être meilleur qu'eux?
Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux (avec des vrais serveurs, hein)?
Les attaques gratuites sur OVH, c'est lourd.
[^] # Re: Pas facile de ce prononcer...
Posté par briaeros007 . Évalué à 10.
D'un coup ca diminue un peu ton chiffre.
[^] # Re: Pas facile de ce prononcer...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Pas facile de ce prononcer...
Posté par briaeros007 . Évalué à 3.
J'ai pas dis que le nombre de serveurs qu'ils géraient étaient à "0" , mais que si ils ont 50 000 serveurs dont 30 000 de dédiées, c'est pas tout a fait la même chose
De plus, ils monitorent aussi leur réseau pour couper les serveurs compromis.
Ce qui n'est absolument pas leur boulot (et si j'ai envie de payer pour un honey pot, je fais comment ?) (et si j'ai un traffic qui peut faire penser à une DDoS mais qui est un test de charge ?)
[^] # Re: Pas facile de ce prononcer...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pas facile de ce prononcer...
Posté par briaeros007 . Évalué à 6.
[^] # Re: Pas facile de ce prononcer...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Parce mes stats perso - à ma petite échelle - montrent très souvent soit des spams en provenance d'OVH, soit pour des sites hébergés chez eux, mais je n'ai jamais vu de réponse de leur abuse@.
[^] # Re: Pas facile de ce prononcer...
Posté par Kerro . Évalué à 2.
J'ai testé en début d'année depuis un dédié 1 Gb/s chez OVH pour trouver des serveurs d'administration Kaspersky. J'ai scanné genre brute épaisse les adresses jusqu'à je crois 120.0.0.0 en quelques heures sur 2 ports.
Conclusion du test: il y a bel et bien une grande facilité pour récupérer des clefs de licences Kaspersky. Incroyable la nullité de beaucoup d'administrateurs.
Je n'ai pas osé tester le mot de passe par défaut, mais là ce serait le ponpon: contrôle à 100% sur les clients connectés :-)
[^] # Re: Pas facile de ce prononcer...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pas facile de ce prononcer...
Posté par Kerro . Évalué à 6.
Une phrase d'un collègue m'a fait soupçonner un problème avec une facilité offerte par les serveurs d'administration Kaspersky. Ce sont les serveurs des entreprises qui ont un certain nombre de machines à administrer au niveau de l'anti-virus, et donc elles mettent en place un serveur d'administration Kaspersky au lieu de tout se palucher à la mimine.
J'ai testé chez nous, le problème est réel. J'ai pour cela mis en route la facilité en question, car elle ne nous sert pas... et j'ai horreur de ces soi-disant facilités qui font toujours des trucs dans ton dos.
Après ça, je me suis dit qu'il existe probablement des milliers de serveurs d'administration Kaspersky accessibles sur les ports standards ET avec la facilité activée. D'où mon scan de machines. J'avais scanné 3 port en fait. Les deux ports Kaspersky, plus un port bidon sensé être fermé, afin d'éviter trop de faux positifs.
Le scan m'a ramené plus d'une centaine de machines (donc pas des milliers finalement). Sur le lot, beaucoup étaient visiblement autre chose que ce que je voulais. Les quelques autres que j'ai testé étaient presque toutes des serveurs Kaspersky. Et presque toutes avec la facilité activée. Je connecte un poste fraîchement installé (et surtout à réinstaller illico) sur le premier serveur trouvé... une clef de licence. Sur le second... une clef. Etc :-)
La facilité en question permet d'attribuer automatiquement une licence aux clients qui se connectent. Ca évite à l'admin d'avoir à être compétent.
En gros, ça permet d'avoir des licences facilement. Mais bon, il y a déjà un site web rempli de licences Kaspersky valides. Ca permet surtout de consommer toutes les licences d'une victime.
Le pire: si un serveur a toujours le mot de passe par défaut, tu peux ouvrir la console d'administration (librement récupérable chez Kapersky), créer un paquet d'installation maison (avec la charge voulue), déployer ce paquet sur les postes... et boum :-)
J'ai dans l'idée que beaucoup de ces serveurs ont le mot de passe par défaut.
[^] # Re: Pas facile de ce prononcer...
Posté par Olivier (site web personnel) . Évalué à 3.
Mais ces types ont des Classe B ou C publiques ou quoi ? C'est donner de la confiture au chochons ca !
Et ils sont payés pour faire ce type de boulettes ?
Je comprends mieux pourquoi des "gros" réseaux ont tant de problème de sécurité...
Ca permet surtout de consommer toutes les licences d'une victime.
Je sais que c'est de l'humour. Mais j'imagine la tête de l'admin de la machine lorsqu'il s'apercevra qu'il n'a plus de clés de dispo.. ;)
[^] # Re: Pas facile de ce prononcer...
Posté par Kerro . Évalué à 2.
C'était une de mes préoccupations. Je voulais savoir si nous étions soumis à ce risque (donc oui si nous ne faisons pas attention, donc comment supprimer le risque quasi-totalement ?).
[^] # Re: Pas facile de ce prononcer...
Posté par herodiade . Évalué à 10.
Alors :
1- Ils ne gèrent eux-même qu'une fraction des serveurs qu'ils hébèrgent.
2- Vu les merdes que remontent mes services et mon fw (bots scannant depuis des serveurs voisins), en nombre bien plus conséquent que chez mes autres et mes précédents hébergeurs, je ne dirait pas qu'ils s'en sortent bien
> Tu peux amener une preuve que tu sais gérer des machines mieux qu'eux
J'aurais tendance à dire que c'est à eux d'amener la preuve qu'ils fournissent autre chose que de la "snake oil security" vu que :
- Ils ont des prétentions dans ce sens (voir leur com')
- C'est eux qui vendent des services, pas moi.
- Ils installent d'office un frankenkernel "grsec" contre l'avis des spécialistes du kernel au sujet de ce patchset (les mainteneurs), et bien sûr compilé sans SELinux. "Qui sont-ils pour prétendre mieux savoir que les devs du kernel eux-même ?".
- Ils l'installent aussi lorsqu'ils fournissent des serveurs installés avec autre chose que leur distro cocasse. Par exemple ils fournissent les Debian avec leur kernel (installé et booté). "Qui sont-ils pour prétendre mieux faire que les fournisseurs de ma distro ?".
Pour donner tout son sel au dernier point (les Debian sont installées sans le kernel standard de la distro), il faut préciser que la kermerde qu'ovh nous inflige _n'est pas packagée_ (ils posent un bzimage dans /boot et basta). Histoire de donner de bonnes chances aux users de louper les upgrades sécu importantes telles que fournis par les canaux usuels de la distro. Chapeau.
Ca ne veux pas dire qu'ils n'ont pas des gens compétents et intelligents en interne, mais il y a de bonnes chances pour qu'il s'agisse d'une de ces boites où un manager/décideur/monsieur-je-sais-tout fort en gueule et ne sachant pas déléguer, au hasard Oles, décide arbitrairement de choses qui le dépasse, et l'équipe technique n'a plus qu'à faire au mieux ... (pure supposition bien sûr...).
De mon point de vue, lorsque quelqu'un s'amuse à distribuer des versions patchées "pour la sécu" de logiciels bien maintenus et développés par des gens compétents, je crois que la preuve de la qualité et fiabilité de l'apport en incombe au amateurs du tuning. Le carnage de l'OpenSSL patché de Debian devrait le montrer assez pour faire réflechir les jackys de service. Le passé de Grsec aussi*.
* http://www.digitalarmaments.com/2007200184936274.html
[^] # Re: Pas facile de ce prononcer...
Posté par Kerro . Évalué à 4.
Sur notre dernier dédié, installé avec Lenny 64-bits, les utilitaires supplémentaires qu'ils ne peuvent s'empêcher de mettre sont en 32-bits. J'ai mis plusieurs minutes avant de comprendre pourquoi ça ne se lancait pas :-)
Et les utilitaires en question c'est quoi ? La surveillance matérielle via leur RealTime Monitoring, rien que ça.
J'arrête, ils se débrouillent globalement très bien. Il faut juste ne pas leur demander pour tel serveur n'est pas joignable de l'extérieur de leur réseau alors qu'il l'est de l'intérieur, ou des choses un peu velues.
[^] # Re: Pas facile de ce prononcer...
Posté par zebra3 . Évalué à 6.
C'est ça que je ne pige pas : ils mettent à jour, sans même connaître la faille. Si ça se trouve, c'est la version qu'ils installent qui apporte la fameuse faille...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas facile de ce prononcer...
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas facile de ce prononcer...
Posté par fearan . Évalué à 2.
c'est par ailleurs la config par défaut sur ma mandriva en niveau de sécurité élevé (je ne sais pas pour le standard)
L'autre sécurité est les login de connexion pas courant, et des mots de passe fort. cependant, pour plus de sécurité j'ai stoppé le serveur ssh (j'en ai pas besoin pour le moment, et le reste de la famille étant en vacance sans accès à internet ça ne peut pas nuire.)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pas facile de ce prononcer...
Posté par zebra3 . Évalué à 3.
Tiens, pareil ce matin...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas facile de ce prononcer...
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: Pas facile de ce prononcer...
Posté par Babelouest (site web personnel) . Évalué à 2.
Cela dit, s'il y a moyen de passer par une console d'admin web ultra sécurisée (avec mdp+certificat pas public+autre systèmes de sécu pour parano inconsolable) pour rajouter à la volée les IP accessibles dans la conf iptables pour ssh, je suis preneur.
[^] # Re: Pas facile de ce prononcer...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Pas facile de ce prononcer...
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Pas facile de ce prononcer...
Posté par Kerro . Évalué à 3.
Quelles mesures de protection prenez vous ?
Pour moi:
- port 22 avec un démon ssh_bidon qui refuse toutes les connexions
- port xxx avec le vrai ssh
- fail2ban après 2 tentatives, banissement sur tous les ports pendant 24 heures
- root ne peut pas se connecter directement en ssh
Il faudrait que j'ajoute:
- portknockd ou fwknop
- des clefs, mais je dois me connecter depuis beaucoup d'endroits différents et pas toujours avec une machine qui m'appartient. Dans ce cas il me faudrait probablement un mot de passe qui change à chaque connexion. Ca fonctionne bien mais je ne l'ai pas industrialisé chez nous.
[^] # Re: Pas facile de ce prononcer...
Posté par Benoit . Évalué à 9.
Qui, avec une zero day dans openssh et toutes les possibilités que ça offre, irait se faire chier à attaquer astalavista.com ?
[^] # Re: Pas facile de ce prononcer...
Posté par X345 . Évalué à 2.
Apparemment, en outre, la faille de sécurité ne concernerait que des anciennes versions d'OpenSSH... Mais il est clair qu'il doit y avoir bien plus intéressant et bien plus tentant à attaquer !
[^] # Re: Pas facile de ce prononcer...
Posté par Epy . Évalué à 4.
[^] # Re: Pas facile de ce prononcer...
Posté par briaeros007 . Évalué à 4.
[^] # Re: Pas facile de ce prononcer...
Posté par thedude . Évalué à 1.
Ca les a peut etre motive pour le rm -rf / cela dit.
[^] # Re: Pas facile de ce prononcer...
Posté par Raphaël SurcouF (site web personnel) . Évalué à -1.
[^] # Re: Pas facile de ce prononcer...
Posté par Georges Dubus (site web personnel) . Évalué à 4.
Ça sert à rien : on aurait une simple augmentation statistique des récits d'attaques, et on pourrait rien en déduire de plus.
# Ce qu'en disent les mailing lists
Posté par dohzya . Évalué à 1.
# Open0wn
Posté par Greg (site web personnel) . Évalué à 1.
# openvpn
Posté par tuxsmouf . Évalué à 2.
Personnellement, je n'ouvre ssh que pour l'addresse IP de mon boulot car je l'estime être de confiance. Pour le reste, c'est openvpn pour pouvoir accéder au ssh de ma machine.
[^] # Re: openvpn
Posté par Greg (site web personnel) . Évalué à 3.
ChallengeResponseAuthentication no
# FUD ?
Posté par Greg (site web personnel) . Évalué à 2.
# Væ victis
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
http://news.softpedia.com/news/Rogue-OpenSSH-0-Day-Exploit-D(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.