mon serveur vient de se faire hacké.
Le mot de passe root a été changé, mais, pas celui de postgres.
Je peux donc encore me connecter en ssh via ce compte.
Connaissez-vous une méthode pour reprendre la main sur root et rechanger
le pw ?
By the way, par où dois-je commencer pour essayer de comprendre par où
il est passé ?
D'avance, merci pour votre aide.
Avr.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/1377518719.16203.5.camel@phenom.lan
@DC : Fail2Ban est un script surveillant les accès réseau grâce aux l ogs des serveurs. Lorsqu'il détecte des erreurs d'authentification répét ées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables. Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par iptables.
<div dir="ltr">@Julien : merci pour tes conseils.<div><br></div><div styl e>@DC : Fail2Ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu'il détecte des erreurs d'authentificat ion répétées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables.</div> Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par ip tables.<br><div><br></div></div>
--047d7b60457c5d2a0504e4ece683--
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/CAJeHwDYN4Y+
@DC : Fail2Ban est un script surveillant les accès réseau grâce aux l ogs
des serveurs. Lorsqu'il détecte des erreurs d'authentification répét ées, il
prend des contre-mesures en bannissant l'adresse IP grâce à iptables.
Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par
iptables.
<div dir="ltr">@Julien : merci pour tes conseils.<div><br></div><div styl e>@DC : Fail2Ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu'il détecte des erreurs d'authentificat ion répétées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables.</div>
Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par ip tables.<br><div><br></div></div>
--047d7b60457c5d2a0504e4ece683--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAJeHwDYN4Y+uTbPcCGyq5YjPfs1d5VnsPCcVj1B1-gNCZqD8Yw@mail.gmail.com
@DC : Fail2Ban est un script surveillant les accès réseau grâce aux l ogs des serveurs. Lorsqu'il détecte des erreurs d'authentification répét ées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables. Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par iptables.
<div dir="ltr">@Julien : merci pour tes conseils.<div><br></div><div styl e>@DC : Fail2Ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu'il détecte des erreurs d'authentificat ion répétées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables.</div> Fail2Ban consomme en général 10 Mo. Le reste du travail est fait par ip tables.<br><div><br></div></div>
--047d7b60457c5d2a0504e4ece683--
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/CAJeHwDYN4Y+
Johnny B
Le 08/27/2013 11:30 AM, Daniel Caillibaud a écrit :
Le 26/08/13 à 17:08, honeyshell a écrit : H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh, H> ainsi que l'installation de Fail2Ban. H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser que ta clé, qui elle a une passphrase).
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir
Il est évident qu'un attaquant persévérant testera du bruteforce, c'est un principe de base logique de poser un pass strong meme avec un auth via clef publique. (les attaques peuvent aussi venir de la console physique)
si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec "PasswordAuthentication no") .
Evidemment qu'ils ont un interet et n'ont rien a voir avec "PasswordAuthentication no" , fail2ban et port knocking agissent avant une négo avec le serveur SSH ce sont des outils nécessaire voir indispensables, encore faut il savoir les utiliser et ne pas juste faire un apt-get install et les laisser en plan
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée, c'est de l'illusion de sécurité).
C'est aussi un principe de base. Il n'y a pas 1 solution à la sécurité. C'est un composé de plusieurs actions et méthodes. Si le port est modifié, l'attaquant va perdre un temps fou a catcher le port ssh et peut abandonner pour trouver une autre faille. Contruire un archi sécurisée c'est aussi se baser sur plusieurs composantes et faire perdre du temps à un attaquant est une action sécuritaire de base. Un firewall mal configuré est aussi une illusion de sécurité, donc oui modifier le port est une action qui ajoute 1+ dans toute la configuration d'une sécurisation
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 08/27/2013 11:30 AM, Daniel Caillibaud a écrit :
Le 26/08/13 à 17:08, honeyshell <honeyshell@honeyshell.com> a écrit :
H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh,
H> ainsi que l'installation de Fail2Ban.
H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de
H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur
H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser
que ta clé, qui elle a une passphrase).
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir
Il est évident qu'un attaquant persévérant testera du bruteforce, c'est
un principe de base logique de poser un pass strong meme avec un auth
via clef publique. (les attaques peuvent aussi venir de la console physique)
si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec
"PasswordAuthentication no") .
Evidemment qu'ils ont un interet et n'ont rien a voir avec
"PasswordAuthentication no" , fail2ban et port knocking agissent avant
une négo avec le serveur SSH ce sont des outils nécessaire voir
indispensables, encore faut il savoir les utiliser et ne pas juste faire
un apt-get install et les laisser en plan
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée,
c'est de l'illusion de sécurité).
C'est aussi un principe de base. Il n'y a pas 1 solution à la sécurité.
C'est un composé de plusieurs actions et méthodes. Si le port est
modifié, l'attaquant va perdre un temps fou a catcher le port ssh et
peut abandonner pour trouver une autre faille. Contruire un archi
sécurisée c'est aussi se baser sur plusieurs composantes et faire perdre
du temps à un attaquant est une action sécuritaire de base. Un firewall
mal configuré est aussi une illusion de sécurité, donc oui modifier le
port est une action qui ajoute 1+ dans toute la configuration d'une
sécurisation
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521CA068.1070206@gmail.com
Le 08/27/2013 11:30 AM, Daniel Caillibaud a écrit :
Le 26/08/13 à 17:08, honeyshell a écrit : H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh, H> ainsi que l'installation de Fail2Ban. H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser que ta clé, qui elle a une passphrase).
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir
Il est évident qu'un attaquant persévérant testera du bruteforce, c'est un principe de base logique de poser un pass strong meme avec un auth via clef publique. (les attaques peuvent aussi venir de la console physique)
si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec "PasswordAuthentication no") .
Evidemment qu'ils ont un interet et n'ont rien a voir avec "PasswordAuthentication no" , fail2ban et port knocking agissent avant une négo avec le serveur SSH ce sont des outils nécessaire voir indispensables, encore faut il savoir les utiliser et ne pas juste faire un apt-get install et les laisser en plan
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée, c'est de l'illusion de sécurité).
C'est aussi un principe de base. Il n'y a pas 1 solution à la sécurité. C'est un composé de plusieurs actions et méthodes. Si le port est modifié, l'attaquant va perdre un temps fou a catcher le port ssh et peut abandonner pour trouver une autre faille. Contruire un archi sécurisée c'est aussi se baser sur plusieurs composantes et faire perdre du temps à un attaquant est une action sécuritaire de base. Un firewall mal configuré est aussi une illusion de sécurité, donc oui modifier le port est une action qui ajoute 1+ dans toute la configuration d'une sécurisation
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Daniel Caillibaud
Le 27/08/13 à 13:40, julien a écrit : J> Le 2013-08-27 13:14, Daniel Caillibaud a écrit : J> > Le 27/08/13 à 12:32, julien a écrit : J> > J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y J> > J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la ja il J> > J> > permet de moins solliciter ton service ssh. C'est déjà un plu s. J> > J> J> > J> Oui et ça permet surtout d'économiser la bande passante J> > J> > C'est pas négligeable devant les ressources consommées par fail2ba n ? J> J> Fail2ban consomme un peu de CPU c'est tout.
Et des I/O disques (grep sur les logs).
J> Dans le cas d'un serveur J> dédié, il y a un quota de bande passante. C'est donc la bande passan te J> que je veux limiter.
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump pendant une tentative).
-- Daniel
C'est quand on serre une dame de trop prés qu'elle trouve qu'on va trop loin. Alphonse Allais
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 27/08/13 à 13:40, julien <julien@nura.eu> a écrit :
J> Le 2013-08-27 13:14, Daniel Caillibaud a écrit :
J> > Le 27/08/13 à 12:32, julien <julien@nura.eu> a écrit :
J> > J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
J> > J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la ja il
J> > J> > permet de moins solliciter ton service ssh. C'est déjà un plu s.
J> > J>
J> > J> Oui et ça permet surtout d'économiser la bande passante
J> >
J> > C'est pas négligeable devant les ressources consommées par fail2ba n ?
J>
J> Fail2ban consomme un peu de CPU c'est tout.
Et des I/O disques (grep sur les logs).
J> Dans le cas d'un serveur
J> dédié, il y a un quota de bande passante. C'est donc la bande passan te
J> que je veux limiter.
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours
les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute
un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer
en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump
pendant une tentative).
--
Daniel
C'est quand on serre une dame de trop prés qu'elle trouve
qu'on va trop loin.
Alphonse Allais
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130827150226.422e3c14@lairdutemps.org
Le 27/08/13 à 13:40, julien a écrit : J> Le 2013-08-27 13:14, Daniel Caillibaud a écrit : J> > Le 27/08/13 à 12:32, julien a écrit : J> > J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y J> > J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la ja il J> > J> > permet de moins solliciter ton service ssh. C'est déjà un plu s. J> > J> J> > J> Oui et ça permet surtout d'économiser la bande passante J> > J> > C'est pas négligeable devant les ressources consommées par fail2ba n ? J> J> Fail2ban consomme un peu de CPU c'est tout.
Et des I/O disques (grep sur les logs).
J> Dans le cas d'un serveur J> dédié, il y a un quota de bande passante. C'est donc la bande passan te J> que je veux limiter.
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump pendant une tentative).
-- Daniel
C'est quand on serre une dame de trop prés qu'elle trouve qu'on va trop loin. Alphonse Allais
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Christophe
Bonjour,
Le 27/08/2013 15:02, Daniel Caillibaud a écrit :
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump pendant une tentative).
Sans parler de serveur dédié, moi qui suis derrière un lien particulièrement faible, je sens très clairement la différence avec/sans : quand je suis au téléphone (SIP de bout en bout, pas sur une Box) et fail2ban désactivé, je le sais tout de suite quand il y a une tentative qui dure un peu dans le temps ;). Accessoirement, ne n'autorise pas les authentifications par mot de passe.
En ce sens, je trouve qu'il y a un intérêt.
A première vue, Je ne pense pas tant que cela soit le nombre d'octets/s qui soit important, mais plutôt le nombre de packets/s dans le cas présent.
@+ Christophe.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
Le 27/08/2013 15:02, Daniel Caillibaud a écrit :
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours
les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute
un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer
en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump
pendant une tentative).
Sans parler de serveur dédié, moi qui suis derrière un lien
particulièrement faible, je sens très clairement la différence avec/sans
: quand je suis au téléphone (SIP de bout en bout, pas sur une Box) et
fail2ban désactivé, je le sais tout de suite quand il y a une tentative
qui dure un peu dans le temps ;).
Accessoirement, ne n'autorise pas les authentifications par mot de passe.
En ce sens, je trouve qu'il y a un intérêt.
A première vue, Je ne pense pas tant que cela soit le nombre d'octets/s
qui soit important, mais plutôt le nombre de packets/s dans le cas présent.
@+
Christophe.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521CAA0F.6070400@stuxnet.org
J'ai jamais réussi à atteindre mes 100Mbs de limite de BP sans utiliser des SSD, j'ai toujours les I/O disques qui limitent avant.
Ceci dit j'ai utilisé fail2ban pendant des années, mais si les mdp sont pas autorisés je doute un peu de son intérêt (je me demande ce qu'une attaque bien bourrine en ssh pourrait consommer en BP, j'ai l'impression que ça doit pas faire bcp d'octets / s, faudrait mesurer avec tcpdump pendant une tentative).
Sans parler de serveur dédié, moi qui suis derrière un lien particulièrement faible, je sens très clairement la différence avec/sans : quand je suis au téléphone (SIP de bout en bout, pas sur une Box) et fail2ban désactivé, je le sais tout de suite quand il y a une tentative qui dure un peu dans le temps ;). Accessoirement, ne n'autorise pas les authentifications par mot de passe.
En ce sens, je trouve qu'il y a un intérêt.
A première vue, Je ne pense pas tant que cela soit le nombre d'octets/s qui soit important, mais plutôt le nombre de packets/s dans le cas présent.
@+ Christophe.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
BERTRAND Joël
Daniel Caillibaud wrote:
Le 26/08/13 à 17:08, honeyshell a écrit : H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh, H> ainsi que l'installation de Fail2Ban. H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser que ta clé, qui elle a une passphrase).
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec "PasswordAuthentication no") .
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée, c'est de l'illusion de sécurité).
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
Cordialement,
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Daniel Caillibaud wrote:
Le 26/08/13 à 17:08, honeyshell<honeyshell@honeyshell.com> a écrit :
H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh,
H> ainsi que l'installation de Fail2Ban.
H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de
H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur
H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser
que ta clé, qui elle a une passphrase).
Certes, mais cela oblige aussi de faire confiance à la machine hôte.
Lorsque je suis chez un client, je ne fais pas confiance à sa machine a
priori. Je ne lui donne donc pas ma clef.
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir
si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec
"PasswordAuthentication no") .
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée,
c'est de l'illusion de sécurité).
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des
mots de passe un tant soit peu complexes, on évite déjà pas mal de
problèmes.
Cordialement,
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521CC181.5070904@systella.fr
Le 26/08/13 à 17:08, honeyshell a écrit : H> Je te joints à ce mail mon tuto pour l'installation/configuration de ssh, H> ainsi que l'installation de Fail2Ban. H> Avec cette configuration tu seras à l'abris des "boots" qui tentent de H> détecter les accès SSH peu sécurisés (mot de passe en root uniquement) sur H> le port 22.
Le plus simple (et secure) reste quand même d'interdire l'accès par mot de passe (n'autoriser que ta clé, qui elle a une passphrase).
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Pas besoin de se poser de question sur la solidité du pass (sinon celui de la clé) ni de savoir si fail2ban ou le portknocking est efficace (ils me paraissent sans aucun intérêt avec "PasswordAuthentication no") .
Et pas besoin non plus de changer le port ssh (cacher la porte ne la rend pas mieux blindée, c'est de l'illusion de sécurité).
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
Cordialement,
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Harang Jean-Marc
Le 27/08/2013 17:10, BERTRAND Joël a écrit :
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw de base quand même et que j'ai 0 problème. je précise que je n'ai que très peu d'applications web en PHP, ça doit aider aussi ...
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut être instructif, en particulier pour des gens comme moi dont ce n'est pas le métier ;) Juste quelques points clefs, hein :)
merci -- jean-marc
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 27/08/2013 17:10, BERTRAND Joël a écrit :
Avec un ssh qui évite le compte root, un fail2ban bien configuré
et des mots de passe un tant soit peu complexes, on évite déjà pas mal
de problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw
de base quand même et que j'ai 0 problème. je précise que je n'ai que
très peu d'applications web en PHP, ça doit aider aussi ...
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut
être instructif, en particulier pour des gens comme moi dont ce n'est
pas le métier ;) Juste quelques points clefs, hein :)
merci
--
jean-marc
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521CCCE9.9030504@c-s.fr
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw de base quand même et que j'ai 0 problème. je précise que je n'ai que très peu d'applications web en PHP, ça doit aider aussi ...
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut être instructif, en particulier pour des gens comme moi dont ce n'est pas le métier ;) Juste quelques points clefs, hein :)
merci -- jean-marc
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
BERTRAND Joël
Harang Jean-Marc wrote:
Le 27/08/2013 17:10, BERTRAND Joël a écrit :
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw de base quand même et que j'ai 0 problème. je précise que je n'ai que très peu d'applications web en PHP, ça doit aider aussi ...
Ça aide aussi ;-)
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut être instructif, en particulier pour des gens comme moi dont ce n'est pas le métier ;) Juste quelques points clefs, hein :)
Ne pas garder la configuration par défaut. Je ne sais pas comment est livré actuellement fail2ban, mais sur mes machines, il ne fait pas que regarder ssh. Il regarde tous les auters services potentiellement dangereux et banni plus rapidement les IP (et pour des durées d'autant plus longues que l'origine est bizarre... Je me connecte rarement en ssh depuis la Chine ou depuis un réseau zombie).
Et bien configuré, cela veut dire aussi regarder ce qui se passe sur le réseau interne. La seule machine qui est tombée sur l'un de mes réseaux a subi une attaque depuis un PC vérolé. On ne pense pas trop à cela sur les petits réseaux.
Et toujours ceinture _et_ bretelle. Le but n'est pas d'interdire à quelqu'un d'entrer sur des machines mais de le ralentir le plus possible.
Cordialement,
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Harang Jean-Marc wrote:
Le 27/08/2013 17:10, BERTRAND Joël a écrit :
Avec un ssh qui évite le compte root, un fail2ban bien configuré et
des mots de passe un tant soit peu complexes, on évite déjà pas mal de
problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw
de base quand même et que j'ai 0 problème. je précise que je n'ai que
très peu d'applications web en PHP, ça doit aider aussi ...
Ça aide aussi ;-)
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut
être instructif, en particulier pour des gens comme moi dont ce n'est
pas le métier ;) Juste quelques points clefs, hein :)
Ne pas garder la configuration par défaut. Je ne sais pas comment est
livré actuellement fail2ban, mais sur mes machines, il ne fait pas que
regarder ssh. Il regarde tous les auters services potentiellement
dangereux et banni plus rapidement les IP (et pour des durées d'autant
plus longues que l'origine est bizarre... Je me connecte rarement en ssh
depuis la Chine ou depuis un réseau zombie).
Et bien configuré, cela veut dire aussi regarder ce qui se passe sur le
réseau interne. La seule machine qui est tombée sur l'un de mes réseaux
a subi une attaque depuis un PC vérolé. On ne pense pas trop à cela sur
les petits réseaux.
Et toujours ceinture _et_ bretelle. Le but n'est pas d'interdire à
quelqu'un d'entrer sur des machines mais de le ralentir le plus possible.
Cordialement,
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521CD189.90806@systella.fr
Avec un ssh qui évite le compte root, un fail2ban bien configuré et des mots de passe un tant soit peu complexes, on évite déjà pas mal de problèmes.
bonsoir,
c'est vrai que je me suis contenté de ça sur mon dédié perso, avec un fw de base quand même et que j'ai 0 problème. je précise que je n'ai que très peu d'applications web en PHP, ça doit aider aussi ...
Ça aide aussi ;-)
Mais qu'entends-tu par "fail2ban bien configuré" ? je pense que ça peut être instructif, en particulier pour des gens comme moi dont ce n'est pas le métier ;) Juste quelques points clefs, hein :)
Ne pas garder la configuration par défaut. Je ne sais pas comment est livré actuellement fail2ban, mais sur mes machines, il ne fait pas que regarder ssh. Il regarde tous les auters services potentiellement dangereux et banni plus rapidement les IP (et pour des durées d'autant plus longues que l'origine est bizarre... Je me connecte rarement en ssh depuis la Chine ou depuis un réseau zombie).
Et bien configuré, cela veut dire aussi regarder ce qui se passe sur le réseau interne. La seule machine qui est tombée sur l'un de mes réseaux a subi une attaque depuis un PC vérolé. On ne pense pas trop à cela sur les petits réseaux.
Et toujours ceinture _et_ bretelle. Le but n'est pas d'interdire à quelqu'un d'entrer sur des machines mais de le ralentir le plus possible.
Cordialement,
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
julien
Le 2013-08-27 17:10, BERTRAND Joël a écrit :
Daniel Caillibaud wrote:
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Julien
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 2013-08-27 17:10, BERTRAND Joël a écrit :
Daniel Caillibaud wrote:
Certes, mais cela oblige aussi de faire confiance à la machine hôte.
Lorsque je suis chez un client, je ne fais pas confiance à sa machine
a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Julien
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/69d404992b033de1dbf5280ad02429fe@127.0.0.1nura.eu
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Julien
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
BERTRAND Joël
julien wrote:
Le 2013-08-27 17:10, BERTRAND Joël a écrit :
Daniel Caillibaud wrote:
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Oui, largement. Je ne laisse pas une clef sur une machine peut-être compromise. Pour les connexions depuis ce genre de machine, j'ai un compte spécial avec un mot de passe qui change à chaque connexion réussie.
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
julien wrote:
Le 2013-08-27 17:10, BERTRAND Joël a écrit :
Daniel Caillibaud wrote:
Certes, mais cela oblige aussi de faire confiance à la machine hôte.
Lorsque je suis chez un client, je ne fais pas confiance à sa machine
a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Oui, largement. Je ne laisse pas une clef sur une machine peut-être
compromise. Pour les connexions depuis ce genre de machine, j'ai un
compte spécial avec un mot de passe qui change à chaque connexion réussie.
JKB
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/521DC719.4070807@systella.fr
Certes, mais cela oblige aussi de faire confiance à la machine hôte. Lorsque je suis chez un client, je ne fais pas confiance à sa machine a priori. Je ne lui donne donc pas ma clef.
Et tu préfères taper ton mot de passe sur son clavier ?
Oui, largement. Je ne laisse pas une clef sur une machine peut-être compromise. Pour les connexions depuis ce genre de machine, j'ai un compte spécial avec un mot de passe qui change à chaque connexion réussie.
JKB
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
