Protection contre attaque Port scan sur serveur privée Linux Amen
48 réponses
llnis
Bonjour à tous,
J'ai un serveur privée Linux chez Amen.
Amen à été contraint de suspendre brutalement mon serveur.
Ils l'annoncent compromis et à l'origine d'attaques Port scan.
Les conséquences sont énormes, car la suspension entraîne, après récupération des données théoriquement infectées, ( après isolement, le serveur à été mis en mode recovery) la réinitialisation complète du serveur, et la perte totale des configurations initiales de tous les sites hébergés (www, bdd, qmail).
De plus, même si les BDD et les Domaines sont récupérables (là encore en théorie), les comptes de messagerie, sont inexorablement perdus, et devront être reconfigurés 1 par 1 à la main. L'information à l'attention de chaque usager s'avère alors difficile à réaliser, en l'absence le plus souvent d'alias email, dans la mesure aussi, ou le MP aura fatalement été réinitialisé.
Amen argue que je suis censé organiser et protéger moi-même mon serveur de ce type d'attaques et de recherches d'intrusion, raison pour laquelle la suspension totale du serveur à été appliqué.
Aussi, auriez-vous réponses à ces questions :
Que pourrai-je installer comme application compatible, sur un serveur privée Linux d'Amen, apte à protéger celui-ci, et à me signaler en temps réel, toute intrusion potentiellle en cours ?
Comment gérer l'ouverture ou la fermeture des ports, le serveur privée d'Amen étant, dans la réalité, un serveur virtuel ?
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre qu'un mot de passe, et même si la plupart des programmes sont conçus pour éviter de laisser filtrer l'information trop facilement, tu n'as aucune garantie que ce soit le cas de tous, et l'audit dans ce sens est largement moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le suggères, est de toutes façons suicidaire.
JKB , dans le message <slrnjobbeh.qpt.jkb@rayleigh.systella.fr>, a
écrit :
Parce que si je suis l'attaquant, connaître le nom du compte à
attaquer, soit ici root, c'est déjà avoir la moitié de la solution.
Alors que si je n'ai pas l'information du nom du compte, il va me
falloir faire des tests sur le login et le mot de passe (et mon ssh
ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre
qu'un mot de passe, et même si la plupart des programmes sont conçus pour
éviter de laisser filtrer l'information trop facilement, tu n'as aucune
garantie que ce soit le cas de tous, et l'audit dans ce sens est largement
moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le
suggères, est de toutes façons suicidaire.
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre qu'un mot de passe, et même si la plupart des programmes sont conçus pour éviter de laisser filtrer l'information trop facilement, tu n'as aucune garantie que ce soit le cas de tous, et l'audit dans ce sens est largement moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le suggères, est de toutes façons suicidaire.
Luc.Habert.00__arjf
JKB :
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant doit déjà connaître le login 837js765 de mon serveur, c'est plus délicat.
Et avec login root et passwd 836js765 concaténé au passwd actuel, ça nécessite autant de bourrinage pour l'attaquant.
JKB :
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant
doit déjà connaître le login 837js765 de mon serveur, c'est plus
délicat.
Et avec login root et passwd 836js765 concaténé au passwd actuel, ça
nécessite autant de bourrinage pour l'attaquant.
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant doit déjà connaître le login 837js765 de mon serveur, c'est plus délicat.
Et avec login root et passwd 836js765 concaténé au passwd actuel, ça nécessite autant de bourrinage pour l'attaquant.
Vincent Verdon
Bonsoir,
Le 11/04/2012 13:11, HAAAAAA, c'est la fin du monde on va tous MOURIR. a écrit : délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Non, mais il est plus compliqué de deviner quel compte permet l'accès. root + mot de passe compliqué c'est moins bien que compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Amicalement, Vincent Verdon
Bonsoir,
Le 11/04/2012 13:11, HAAAAAA, c'est la fin du monde on va tous MOURIR. a
écrit :
délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user
d'avoir les privilèges root (sudo par exemple) ?
Non, mais il est plus compliqué de deviner quel compte permet l'accès.
root + mot de passe compliqué
c'est moins bien que
compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Le 11/04/2012 13:11, HAAAAAA, c'est la fin du monde on va tous MOURIR. a écrit : délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Non, mais il est plus compliqué de deviner quel compte permet l'accès. root + mot de passe compliqué c'est moins bien que compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Amicalement, Vincent Verdon
Sergio
Le Wed, 11 Apr 2012 20:59:09 +0200, Vincent Verdon a écrit :
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Une bonne idée est de ne pas utiliser sudo, mais su (compte_inconnu + 2 mdp compliqués à chercher).
Non, mais il est plus compliqué de deviner quel compte permet l'accès. root + mot de passe compliqué c'est moins bien que compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Glissons un peu de sujet : Peut-on renommer le compte root ? Y'a-t-il contre-indication (par exemple des applis qui cherchent "root" en dur).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le Wed, 11 Apr 2012 20:59:09 +0200, Vincent Verdon a écrit :
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user
d'avoir les privilèges root (sudo par exemple) ?
Une bonne idée est de ne pas utiliser sudo, mais su (compte_inconnu + 2
mdp compliqués à chercher).
Non, mais il est plus compliqué de deviner quel compte permet l'accès.
root + mot de passe compliqué
c'est moins bien que
compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Glissons un peu de sujet : Peut-on renommer le compte root ? Y'a-t-il
contre-indication (par exemple des applis qui cherchent "root" en dur).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Le Wed, 11 Apr 2012 20:59:09 +0200, Vincent Verdon a écrit :
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Une bonne idée est de ne pas utiliser sudo, mais su (compte_inconnu + 2 mdp compliqués à chercher).
Non, mais il est plus compliqué de deviner quel compte permet l'accès. root + mot de passe compliqué c'est moins bien que compte_inconnu + mot de passe compliqué.
Or, tout le monde sait que le compte admin, c'est root.
Glissons un peu de sujet : Peut-on renommer le compte root ? Y'a-t-il contre-indication (par exemple des applis qui cherchent "root" en dur).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Doug713705
Le 12-04-2012, Sergio nous expliquait dans fr.comp.os.linux.configuration :
par exemple des applis qui cherchent "root" en dur
Je vais peut-être dire une bétise mais il me semble que les applis essaient plutôt de connaitre l'uid de l'utilisateur (toujours égal à 0 pour root) plutôt que son nom.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Le 12-04-2012, Sergio nous expliquait dans
fr.comp.os.linux.configuration :
par exemple des applis qui cherchent "root" en dur
Je vais peut-être dire une bétise mais il me semble que les applis
essaient plutôt de connaitre l'uid de l'utilisateur (toujours égal à 0
pour root) plutôt que son nom.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.chainon-marquant.org
http://newsportal.chainon-marquant.org
http://news.chainon-marquant.org
Le 12-04-2012, Sergio nous expliquait dans fr.comp.os.linux.configuration :
par exemple des applis qui cherchent "root" en dur
Je vais peut-être dire une bétise mais il me semble que les applis essaient plutôt de connaitre l'uid de l'utilisateur (toujours égal à 0 pour root) plutôt que son nom.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
JKB
Le 11 Apr 2012 16:53:39 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre qu'un mot de passe, et même si la plupart des programmes sont conçus pour éviter de laisser filtrer l'information trop facilement, tu n'as aucune garantie que ce soit le cas de tous, et l'audit dans ce sens est largement moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le suggères, est de toutes façons suicidaire.
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Apprends au moins à lire.
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 11 Apr 2012 16:53:39 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjobbeh.qpt.jkb@rayleigh.systella.fr>, a
écrit :
Parce que si je suis l'attaquant, connaître le nom du compte à
attaquer, soit ici root, c'est déjà avoir la moitié de la solution.
Alors que si je n'ai pas l'information du nom du compte, il va me
falloir faire des tests sur le login et le mot de passe (et mon ssh
ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre
qu'un mot de passe, et même si la plupart des programmes sont conçus pour
éviter de laisser filtrer l'information trop facilement, tu n'as aucune
garantie que ce soit le cas de tous, et l'audit dans ce sens est largement
moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le
suggères, est de toutes façons suicidaire.
Je n'en fais pas un élément de sécurité. Je prétends simplement que
c'est une information supplémentaire qu'il faut connaître pour
qu'une attaque brutale soit couronnée de succès sur le ssh.
Apprends au moins à lire.
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 11 Apr 2012 16:53:39 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Un login n'est pas censé être une information confidentielle au même titre qu'un mot de passe, et même si la plupart des programmes sont conçus pour éviter de laisser filtrer l'information trop facilement, tu n'as aucune garantie que ce soit le cas de tous, et l'audit dans ce sens est largement moins attentif.
Dans ces conditions, faire du login un élément de sécurité, comme tu le suggères, est de toutes façons suicidaire.
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Apprends au moins à lire.
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
HAAAAAA, c'est la fin du monde on va tous MOURIR.
On Wed, 11 Apr 2012 16:14:10 +0000 (UTC), JKB wrote:
Le Wed, 11 Apr 2012 18:10:07 +0200, HAAAAAA, c'est la fin du monde on va tous MOURIR. écrivait :
On Wed, 11 Apr 2012 11:24:19 +0000 (UTC), JKB wrote:
Le Wed, 11 Apr 2012 13:11:49 +0200, HAAAAAA, c'est la fin du monde on va tous MOURIR. écrivait :
On Wed, 11 Apr 2012 09:18:37 +0000 (UTC), JKB wrote:
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand chose.
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant doit déjà connaître le login 837js765 de mon serveur, c'est plus délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Non, ça n'interdit pas.
Donc, pourquoi interdire root en ssh si un user avec pouvoir peut faire la même chose ?
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Ha ben oui, c'est pas con. ;o))
Et ssh pour moi ne s'envisage pas sans un fail2ban sévère
Pour le moment j'ai pas testé ssh et je me pose justement des questions. - Que pensez vous de portknocker ?
C'est bien. Sauf lorsqu'on doit utiliser un accès depuis une machine tierce qui ne comprend pas facilement la manipulation.
ça c'est pas un problème. On peut creer une page en PHP avec des textbox pour y mettre des nombres et lancer le schmilblick.
C'est juste idiot puisque je peux faire une attaque en force brute dessus (sauf à avoir un .htaccess, mais on rendre dans une usine à gaz que je peux aussi essayer de dégager à coups de bulldozer). Sinon, le honeypot marche aussi pas mal.
Heu, la page en PHP c'est pas livré avec la clé, hein. C'est à toi de rentrer la serie de nombre qui representeront la clé de portknocker. Ces nombres peuvent eventuellement être aleatoire (envoyer par SMS par exemple) ou avec un token générateur de clé temporelle.
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand
chose.
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant
doit déjà connaître le login 837js765 de mon serveur, c'est plus
délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user
d'avoir les privilèges root (sudo par exemple) ?
Non, ça n'interdit pas.
Donc, pourquoi interdire root en ssh si un user avec pouvoir peut faire
la même chose ?
Parce que si je suis l'attaquant, connaître le nom du compte à
attaquer, soit ici root, c'est déjà avoir la moitié de la solution.
Alors que si je n'ai pas l'information du nom du compte, il va me
falloir faire des tests sur le login et le mot de passe (et mon ssh
ne te répondra jamais que le login n'existe pas).
Ha ben oui, c'est pas con. ;o))
Et ssh pour moi ne s'envisage pas sans un fail2ban sévère
Pour le moment j'ai pas testé ssh et je me pose justement des questions.
- Que pensez vous de portknocker ?
C'est bien. Sauf lorsqu'on doit utiliser un accès depuis une machine
tierce qui ne comprend pas facilement la manipulation.
ça c'est pas un problème. On peut creer une page en PHP avec des textbox
pour y mettre des nombres et lancer le schmilblick.
C'est juste idiot puisque je peux faire une attaque en force brute
dessus (sauf à avoir un .htaccess, mais on rendre dans une usine à
gaz que je peux aussi essayer de dégager à coups de bulldozer). Sinon,
le honeypot marche aussi pas mal.
Heu, la page en PHP c'est pas livré avec la clé, hein.
C'est à toi de rentrer la serie de nombre qui representeront la clé de
portknocker.
Ces nombres peuvent eventuellement être aleatoire (envoyer par SMS par
exemple) ou avec un token générateur de clé temporelle.
Bof. C'est une ligne de défense supplémentaire, mais elle ne vaut pas grand chose.
Déjà le fait que root soit un login connu, ça aide. Si l'attaquant doit déjà connaître le login 837js765 de mon serveur, c'est plus délicat.
Quand on interdit l'acces à root en ssh, ça n'empeche pas un user d'avoir les privilèges root (sudo par exemple) ?
Non, ça n'interdit pas.
Donc, pourquoi interdire root en ssh si un user avec pouvoir peut faire la même chose ?
Parce que si je suis l'attaquant, connaître le nom du compte à attaquer, soit ici root, c'est déjà avoir la moitié de la solution. Alors que si je n'ai pas l'information du nom du compte, il va me falloir faire des tests sur le login et le mot de passe (et mon ssh ne te répondra jamais que le login n'existe pas).
Ha ben oui, c'est pas con. ;o))
Et ssh pour moi ne s'envisage pas sans un fail2ban sévère
Pour le moment j'ai pas testé ssh et je me pose justement des questions. - Que pensez vous de portknocker ?
C'est bien. Sauf lorsqu'on doit utiliser un accès depuis une machine tierce qui ne comprend pas facilement la manipulation.
ça c'est pas un problème. On peut creer une page en PHP avec des textbox pour y mettre des nombres et lancer le schmilblick.
C'est juste idiot puisque je peux faire une attaque en force brute dessus (sauf à avoir un .htaccess, mais on rendre dans une usine à gaz que je peux aussi essayer de dégager à coups de bulldozer). Sinon, le honeypot marche aussi pas mal.
Heu, la page en PHP c'est pas livré avec la clé, hein. C'est à toi de rentrer la serie de nombre qui representeront la clé de portknocker. Ces nombres peuvent eventuellement être aleatoire (envoyer par SMS par exemple) ou avec un token générateur de clé temporelle.
Nicolas George
JKB , dans le message , a écrit :
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un élément de sécurité.
JKB , dans le message <slrnjoddsd.gmm.jkb@rayleigh.systella.fr>, a
écrit :
Je n'en fais pas un élément de sécurité. Je prétends simplement que
c'est une information supplémentaire qu'il faut connaître pour
qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un
élément de sécurité.
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un élément de sécurité.
JKB
Le 12 Apr 2012 11:27:24 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un élément de sécurité.
Soit comme d'habitude, tu n'as rien lu/compris.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma boitakon.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 12 Apr 2012 11:27:24 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjoddsd.gmm.jkb@rayleigh.systella.fr>, a
écrit :
Je n'en fais pas un élément de sécurité. Je prétends simplement que
c'est une information supplémentaire qu'il faut connaître pour
qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un
élément de sécurité.
Soit comme d'habitude, tu n'as rien lu/compris.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma
boitakon.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 12 Apr 2012 11:27:24 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Je n'en fais pas un élément de sécurité. Je prétends simplement que c'est une information supplémentaire qu'il faut connaître pour qu'une attaque brutale soit couronnée de succès sur le ssh.
Soit on s'en fout, soit c'est que tu es précisément en train d'en faire un élément de sécurité.
Soit comme d'habitude, tu n'as rien lu/compris.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma boitakon.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
JKB , dans le message , a écrit :
Soit comme d'habitude, tu n'as rien lu/compris.
J'ai parfaitement compris, et je maintiens que ton argument est débile : si tu ne considères pas le login comme un élément de sécurité, tu te fiches qu'il soit connu ou pas.
Contraposée : si tu accordes de l'importance au fait que le login soit connu, c'est que le considères comme un élément de sécurité, ce qui est une mauvaise idée.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma boitakon.
Dit autrement : au fond, tu sais que tes arguments ne valent rien, et tu préviens d'avance que tu n'arriveras pas à les soutenir.
JKB , dans le message <slrnjodgtq.gmm.jkb@rayleigh.systella.fr>, a
écrit :
Soit comme d'habitude, tu n'as rien lu/compris.
J'ai parfaitement compris, et je maintiens que ton argument est débile : si
tu ne considères pas le login comme un élément de sécurité, tu te fiches
qu'il soit connu ou pas.
Contraposée : si tu accordes de l'importance au fait que le login soit
connu, c'est que le considères comme un élément de sécurité, ce qui est une
mauvaise idée.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma
boitakon.
Dit autrement : au fond, tu sais que tes arguments ne valent rien, et tu
préviens d'avance que tu n'arriveras pas à les soutenir.
J'ai parfaitement compris, et je maintiens que ton argument est débile : si tu ne considères pas le login comme un élément de sécurité, tu te fiches qu'il soit connu ou pas.
Contraposée : si tu accordes de l'importance au fait que le login soit connu, c'est que le considères comme un élément de sécurité, ce qui est une mauvaise idée.
Fin de la discussion, réponds ce que tu veux. Et bon retour dans ma boitakon.
Dit autrement : au fond, tu sais que tes arguments ne valent rien, et tu préviens d'avance que tu n'arriveras pas à les soutenir.
