/usr/bin/yes comme mauvaise blague

Le
Vincent Ramos
Bonjour,

Mes logs affichent souvent des tentatives de connexion par ssh avec des
identifiants communs comme root, test, guest, etc., et comme mot de
passe « password » ou le même mot que l'identifiant (test:test, etc.).

Bien sûr, ces tentatives sont vaines. Je me demandais cependant ce que
pourrait entraîner, pour la machine intrusive et la machine « attaquée »
la mauvaise blague suivante :
-- créer un compte « test » et lui donner comme mot de passe «
password » ;
-- lui donner comme shell de connexion /usr/bin/yes.

Cela créerait-il une faille ? J'imagine que si /usr/bin/yes en a une,
elle peut-être exploitable, mais je ne vois pas trop comment on pourrait
interagir avec cette application voire passer à un autre shell à partir
de /usr/bin/yes.

Cela serait-il casse-pieds pour l'intrus ?
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Masson
Le #7075931
Vincent Ramos a écrit :
Bonjour,

Mes logs affichent souvent des tentatives de connexion par ssh avec des
identifiants communs comme root, test, guest, etc., et comme mot de
passe « password » ou le même mot que l'identifiant (test:test, etc.).

Bien sûr, ces tentatives sont vaines. Je me demandais cependant ce que
pourrait entraîner, pour la machine intrusive et la machine « attaquée »
la mauvaise blague suivante :
-- créer un compte « test » et lui donner comme mot de passe «
password » ;
-- lui donner comme shell de connexion /usr/bin/yes.

Cela créerait-il une faille ? J'imagine que si /usr/bin/yes en a une,
elle peut-être exploitable, mais je ne vois pas trop comment on pourrait
interagir avec cette application voire passer à un autre shell à partir
de /usr/bin/yes.

Cela serait-il casse-pieds pour l'intrus ?



Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne
vois pas quel ours serait tenté de rester.
Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que
de ne rien faire.
Si tu ne veux pas voir de connexions sur ssh, change de port et fais du
port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement
beaucoup moins de logs pour ssh.
Vincent Ramos
Le #7079861
Olivier Masson wrote:

Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne
vois pas quel ours serait tenté de rester.



Jolie métaphore.

Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que
de ne rien faire.



C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
Coréens et les Chinois qui, désespérément, pourrissent mes logs.

Si tu ne veux pas voir de connexions sur ssh, change de port et fais du
port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement
beaucoup moins de logs pour ssh.



Pour le changement de ports, je l'ai eu fait. Le problème est qu'une des
machines que j'administre est derrière une passerelle (rectorale) qui
n'ouvre que certains ports et sur laquelle je n'ai aucun droit. Bref,
les ports 22, 80, 25 et 21 sont ouverts et utilisés. Point barre.

Quand au port knocking, je n'ai encore jamais essayé. Vu que j'ai un
système de sauvegardes incrémentales à distance avec rsync par ssh, je
n'ai pas encore cherché à savoir si je peux m'en servir avec cette
application. De même pour monter des systèmes de fichiers distants par
sshfs. Je vais chercher de la doc ; merci pour l'idée.
Fabien LE LEZ
Le #7080051
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :

C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les



...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.

Coréens et les Chinois qui, désespérément, pourrissent mes logs.



Bloque ces deux pays (si tu le peux).

Quand au port knocking, je n'ai encore jamais essayé.



Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des
ports rend le port-knocking inopérant.
mpg
Le #7082951
Le (on) lundi 23 juin 2008 19:16, Fabien LE LEZ a écrit (wrote) :

Coréens et les Chinois qui, désespérément, pourrissent mes logs.



Bloque ces deux pays (si tu le peux).



Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de
bloquer les gens à l'IP d'origine : c'est comme de la discrimination au
faciès.

Quand au port knocking, je n'ai encore jamais essayé.



Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des
ports rend le port-knocking inopérant.



Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban
qui bannit les gens après X tentatives de connexions ratées en moins de N
minutes ? Avec des bonnes valeurs de X et N, ça rend les logs beaucoup plus
propres en stoppant net les attaques par dictionnaire. D'après moins
expérience, peut-être pas significative, les robots n'essayent pas une
deuxième fois après avoir été bloqués 15 minutes.

Et contrairement au port knocking ou au changement de port, d'une part ça ne
fait pas d'hypothèse sur les ports filtrés ou non par la passerelle locale,
et aussi ça ne demande aucune configuration particulière côté utilisateur.

Manuel.
Fabien LE LEZ
Le #7083081
On 23 Jun 2008 23:09:46 GMT, mpg
Coréens et les Chinois qui, désespérément, pourrissent mes logs.



Bloque ces deux pays (si tu le peux).



Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de
bloquer les gens à l'IP d'origine : c'est comme de la discrimination au
faciès.



Il s'agit ici d'un serveur SSH. Il y a donc de bonnes chances pour que
tous les utilisateurs légitimes se connectent depuis l'Europe (en
visant très large). Si c'est bien le cas, bloquer carrément certaines
régions du monde (Russie, Chine, etc.) ne me paraît en rien choquant.

Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban
qui bannit les gens après X tentatives de connexions ratées en moins de N
minutes ?



C'est une solution, à étudier soigneusement avant mise en place pour
éviter le risque de DoS.
Thomas
Le #7083141
In article Fabien LE LEZ
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :

>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
>cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les

...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.



donc la question est :
est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)

si oui,
est il intéressant de leur envoyer que des 0 (cad le caractère NUL),
plutôt que "y<retour>",
pour avoir plus de compression, cad plus de débit virtuel à débit réel
constant, et en plus du travail pour la décompression ?

--
j'agis contre l'assistanat, je travaille dans une SCOP !
jenaipasdemail
Le #7083851
Fabien LE LEZ
>Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban
>qui bannit les gens après X tentatives de connexions ratées en moins de N
>minutes ?

C'est une solution, à étudier soigneusement avant mise en place pour
éviter le risque de DoS.



Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est
une attaque sur un port avec un mauvais login/pwd ET en utilisant une
asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en
faut des attaques (ce qui est réalisable, je sais).

--
Benoit Leraillez

Seuls les idéaux ne changent pas d'avis.
Kevin Denis
Le #7084001
Le 24-06-2008, Thomas
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
>cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les

...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.



donc la question est :
est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)

si oui,
est il intéressant de leur envoyer que des 0 (cad le caractère NUL),
plutôt que "y<retour>",
pour avoir plus de compression, cad plus de débit virtuel à débit réel
constant, et en plus du travail pour la décompression ?



Dans ce cas là, si le but est de ralentir l'assaillant, je conseille
de regarder l'utilisation de la cible TARPIT d'iptables:
TARPIT
Captures and holds incoming TCP connections using no local per-connection
resources. Connections are accepted, but immediately switched to the
persist state (0 byte window), in which the remote side stops sending
data and asks to continue every 60-240 seconds. Attempts to close the
connection are ignored, forcing the remote side to time out the connection
in 12-24 minutes.

man iptables , ou http://linux.die.net/man/8/iptables
--
Kevin
Fabien LE LEZ
Le #7086541
On 24 Jun 2008 01:34:32 GMT, Thomas :

est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)



Peut-être, mais il faut faire attention à ne pas flooder ta machine
par la même occasion.
Stephane Catteau
Le #7087871
Benoit devait dire quelque chose comme ceci :

Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban
qui bannit les gens après X tentatives de connexions ratées en moins de N
minutes ?


C'est une solution, à étudier soigneusement avant mise en place pour
éviter le risque de DoS.



Tu peux me dire comment s'effectue le DoS stp ?



Le plus simple, et qui marche assez bien, est de partir du principe
que l'admin est une feignasse et que le filtrage se fait au niveau du
filtre IP en bordure du réseau. Celui-ci banira toute adresses IP qui
fera, disons plus de 10 (tentatives de) connexions sur un même port en
5 minutes. Comme l'admin est une feignasse, et que mine de rien en
matière de filtrage IP le mieux est parfois l'enemi du bien, il y aura
règles :
1) Les services pouvant nécessiter légitimement plusieurs connexions
courtes (HTTP par exemple) seront exemptées de contrôle. Même chose
pour les services pouvant recevoir de nombreux paquets UDP en un temps
limité (DNS par exemple).
2) Une règle globale traitera le reste des cas de figure, pour être sûr
de ne pas en oublier.

A partir de là, il suffit d'envoyer une vague massive de paquets UDP
en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe
C.
Publicité
Poster une réponse
Anonyme