Sinon, l'attaquant professionnel est capable d'attendre que tu sortes d e
chez toi pour savoir où est ta serrure.
Sinon, l'attaquant professionnel est capable d'attendre que tu sortes d e
chez toi pour savoir où est ta serrure.
Sinon, l'attaquant professionnel est capable d'attendre que tu sortes d e
chez toi pour savoir où est ta serrure.
Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Voilà, merci de ton soutien. C'est exactement le problème de la sé curité par
l'obscurité. Les gens qui font de la sécurité par l'obscurité c onsidèrent un
attaquant professionnel pour attaquer leur système traditionnel et pr ennent
un guignol pour contourner l'obscurité apportée. Alors évidemment , le
conclusion va en leur faveur.
Voilà, merci de ton soutien. C'est exactement le problème de la sé curité par
l'obscurité. Les gens qui font de la sécurité par l'obscurité c onsidèrent un
attaquant professionnel pour attaquer leur système traditionnel et pr ennent
un guignol pour contourner l'obscurité apportée. Alors évidemment , le
conclusion va en leur faveur.
Voilà, merci de ton soutien. C'est exactement le problème de la sé curité par
l'obscurité. Les gens qui font de la sécurité par l'obscurité c onsidèrent un
attaquant professionnel pour attaquer leur système traditionnel et pr ennent
un guignol pour contourner l'obscurité apportée. Alors évidemment , le
conclusion va en leur faveur.
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
On Sun, 02 Oct 2011 14:40:59 +0200, Stephane CARPENTIER
wrote:Qu'est ce qu'elle a ma gueule ? wrote:On Sun, 02 Oct 2011 13:45:44 +0200, Aéris wrote:Ton port 80 ou 22, lui il continue à répondre qu'il y a une port e !
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Ce que tu ne comprends pas, c'est qu'Internet n'est pas un truc un peu
magique sur lequel tu vas chercher des informations au loin.
Au moment où tu vas sur Internet, ton ordinateur fait intégralemen t partie
d'Internet.
Si tu vas visiter un site internet, tu initialises une connexion pour aller
sur le site. Le site distant utilise cette connexion pour envoyer les pages
que tu as demandées. Mais il peut aussi utiliser cette connexion pou r faire
ses propres requêtes.
La sécurité, ce n'est pas d'avoir l'impression d'être invisible, c'est
d'être protégé contre les requêtes dont tu ne veux pas.
Tu ne dois pas configurer ton firewall pour qu'il ne réponde pas à tout sans
discernement, mais pour qu'il refuse proprement ce qui doit être int erdit.
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n' est
pas donnée à la majorité des utilisateurs de machines connectée s à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
On Sun, 02 Oct 2011 14:40:59 +0200, Stephane CARPENTIER
<sc@fiat-linux.fr> wrote:
Qu'est ce qu'elle a ma gueule ? wrote:
On Sun, 02 Oct 2011 13:45:44 +0200, Aéris<aeris@imirhil.fr> wrote:
Ton port 80 ou 22, lui il continue à répondre qu'il y a une port e !
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Ce que tu ne comprends pas, c'est qu'Internet n'est pas un truc un peu
magique sur lequel tu vas chercher des informations au loin.
Au moment où tu vas sur Internet, ton ordinateur fait intégralemen t partie
d'Internet.
Si tu vas visiter un site internet, tu initialises une connexion pour aller
sur le site. Le site distant utilise cette connexion pour envoyer les pages
que tu as demandées. Mais il peut aussi utiliser cette connexion pou r faire
ses propres requêtes.
La sécurité, ce n'est pas d'avoir l'impression d'être invisible, c'est
d'être protégé contre les requêtes dont tu ne veux pas.
Tu ne dois pas configurer ton firewall pour qu'il ne réponde pas à tout sans
discernement, mais pour qu'il refuse proprement ce qui doit être int erdit.
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n' est
pas donnée à la majorité des utilisateurs de machines connectée s à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
On Sun, 02 Oct 2011 14:40:59 +0200, Stephane CARPENTIER
wrote:Qu'est ce qu'elle a ma gueule ? wrote:On Sun, 02 Oct 2011 13:45:44 +0200, Aéris wrote:Ton port 80 ou 22, lui il continue à répondre qu'il y a une port e !
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Ce que tu ne comprends pas, c'est qu'Internet n'est pas un truc un peu
magique sur lequel tu vas chercher des informations au loin.
Au moment où tu vas sur Internet, ton ordinateur fait intégralemen t partie
d'Internet.
Si tu vas visiter un site internet, tu initialises une connexion pour aller
sur le site. Le site distant utilise cette connexion pour envoyer les pages
que tu as demandées. Mais il peut aussi utiliser cette connexion pou r faire
ses propres requêtes.
La sécurité, ce n'est pas d'avoir l'impression d'être invisible, c'est
d'être protégé contre les requêtes dont tu ne veux pas.
Tu ne dois pas configurer ton firewall pour qu'il ne réponde pas à tout sans
discernement, mais pour qu'il refuse proprement ce qui doit être int erdit.
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n' est
pas donnée à la majorité des utilisateurs de machines connectée s à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
Le 02/10/2011 14:04, JKB a écrit :Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions par password
et d'autoriser uniquement celles par clefs RSA =)
Là, même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)…
Le 02/10/2011 14:04, JKB a écrit :
Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions par password
et d'autoriser uniquement celles par clefs RSA =)
Là, même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)…
Le 02/10/2011 14:04, JKB a écrit :Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions par password
et d'autoriser uniquement celles par clefs RSA =)
Là, même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)…
Le 02/10/2011 14:25, Qu'est ce qu'elle a ma gueule ? a écrit :Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Tu peux filtrer par ip source, par exemple sur mon serveur en DMZ,
l'apache et le ssh sont uniquement accessibles à ceux passant par le VPN:
fw -t filter -P INPUT DROP
fw -A INPUT -i tun0 -p tcp --dport ssh -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport http -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport https -j ACCEPT
Tout ce qui ne passe pas par le VPN, c'est direct poubelle sans même
prendre la peine de répondre !
En roue de secours (en cas de merde du VPN), mon adresse IP fixe est
aussi autorisée sur SSH, et uniquement en IPv6 =)
fw6 -A INPUT -p tcp -s X:X:…:X:X --dport ssh -j ACCEPT
(Certains feraient remarquer qu'un spoof d'IP est possible…)
Le 02/10/2011 14:25, Qu'est ce qu'elle a ma gueule ? a écrit :
Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Tu peux filtrer par ip source, par exemple sur mon serveur en DMZ,
l'apache et le ssh sont uniquement accessibles à ceux passant par le VPN:
fw -t filter -P INPUT DROP
fw -A INPUT -i tun0 -p tcp --dport ssh -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport http -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport https -j ACCEPT
Tout ce qui ne passe pas par le VPN, c'est direct poubelle sans même
prendre la peine de répondre !
En roue de secours (en cas de merde du VPN), mon adresse IP fixe est
aussi autorisée sur SSH, et uniquement en IPv6 =)
fw6 -A INPUT -p tcp -s X:X:…:X:X --dport ssh -j ACCEPT
(Certains feraient remarquer qu'un spoof d'IP est possible…)
Le 02/10/2011 14:25, Qu'est ce qu'elle a ma gueule ? a écrit :Ok, donc quelle solution pour ne pas repondre sur le port 80,22,
443,... et ainsi être "invisible" pour autre chose qu'un
administrateur reseau wan/lan ?
Tu peux filtrer par ip source, par exemple sur mon serveur en DMZ,
l'apache et le ssh sont uniquement accessibles à ceux passant par le VPN:
fw -t filter -P INPUT DROP
fw -A INPUT -i tun0 -p tcp --dport ssh -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport http -j ACCEPT
fw -A INPUT -i tun0 -p tcp --dport https -j ACCEPT
Tout ce qui ne passe pas par le VPN, c'est direct poubelle sans même
prendre la peine de répondre !
En roue de secours (en cas de merde du VPN), mon adresse IP fixe est
aussi autorisée sur SSH, et uniquement en IPv6 =)
fw6 -A INPUT -p tcp -s X:X:…:X:X --dport ssh -j ACCEPT
(Certains feraient remarquer qu'un spoof d'IP est possible…)
Le Sun, 02 Oct 2011 13:19:38 +0200,
Qu'est ce qu'elle a ma gueule ? écrivait :On Sun, 02 Oct 2011 13:17:15 +0200, Qu'est ce qu'elle a ma gueule ?
wrote:Ne pas repondre à un ping, n'est ce pas comme cacher la porte ? Pas de
porte, pas de serrure.
Pour cacher la porte, il existe le portknocking.
http://fr.wikipedia.org/wiki/Port_knocking
Ouaips... Sauf que ça implique tout de même un certain nombr e de
considération comme la différence entre un DROP et un REJECT dans
les règles iptables... Un attaquant pourra tout de même savo ir qu'il
y a une machine sur telle adresse. Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par u n
réseau zombie lent de grande dimension).
JKB
Le Sun, 02 Oct 2011 13:19:38 +0200,
Qu'est ce qu'elle a ma gueule ?<nospam@d.email> écrivait :
On Sun, 02 Oct 2011 13:17:15 +0200, Qu'est ce qu'elle a ma gueule ?
<nospam@d.email> wrote:
Ne pas repondre à un ping, n'est ce pas comme cacher la porte ? Pas de
porte, pas de serrure.
Pour cacher la porte, il existe le portknocking.
http://fr.wikipedia.org/wiki/Port_knocking
Ouaips... Sauf que ça implique tout de même un certain nombr e de
considération comme la différence entre un DROP et un REJECT dans
les règles iptables... Un attaquant pourra tout de même savo ir qu'il
y a une machine sur telle adresse. Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par u n
réseau zombie lent de grande dimension).
JKB
Le Sun, 02 Oct 2011 13:19:38 +0200,
Qu'est ce qu'elle a ma gueule ? écrivait :On Sun, 02 Oct 2011 13:17:15 +0200, Qu'est ce qu'elle a ma gueule ?
wrote:Ne pas repondre à un ping, n'est ce pas comme cacher la porte ? Pas de
porte, pas de serrure.
Pour cacher la porte, il existe le portknocking.
http://fr.wikipedia.org/wiki/Port_knocking
Ouaips... Sauf que ça implique tout de même un certain nombr e de
considération comme la différence entre un DROP et un REJECT dans
les règles iptables... Un attaquant pourra tout de même savo ir qu'il
y a une machine sur telle adresse. Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par u n
réseau zombie lent de grande dimension).
JKB
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n'est
pas donnée à la majorité des utilisateurs de machines connectées à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n'est
pas donnée à la majorité des utilisateurs de machines connectées à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
Bon maintenant c'est limpide.
Donc pour avoir une machine sécurisée, il faut un bagage. Ce qui n'est
pas donnée à la majorité des utilisateurs de machines connectées à
internet.
A part RTFM incomprehensible, pour Mme Michu, quelle solution ?
Le Sun, 02 Oct 2011 15:14:52 +0200,
Aéris écrivait :
Le 02/10/2011 14:04, JKB a écrit :Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions p ar password
et d'autoriser uniquement celles par clefs RSA =)
Là , même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)â¦
Et tu te retrouves dans la situation suivante (arrivée chez un
client) : ta clef oubliée sur une machine compromise ! Là , t u es bon
pour te rappeler tous les emplacements de ta fameuse clef et
surtout en te dépêchant ! Je préfère pour ma part un bon mot de passe Ã
une clef qui se balade sur une clef USB (voire par mail comme j'ai dà ©jÃ
vu). Enfin, c'est toi qui voit, hein...
JKB
Le Sun, 02 Oct 2011 15:14:52 +0200,
Aéris<aeris@imirhil.fr> écrivait :
Le 02/10/2011 14:04, JKB a écrit :
Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions p ar password
et d'autoriser uniquement celles par clefs RSA =)
Là , même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)â¦
Et tu te retrouves dans la situation suivante (arrivée chez un
client) : ta clef oubliée sur une machine compromise ! Là , t u es bon
pour te rappeler tous les emplacements de ta fameuse clef et
surtout en te dépêchant ! Je préfère pour ma part un bon mot de passe Ã
une clef qui se balade sur une clef USB (voire par mail comme j'ai dà ©jÃ
vu). Enfin, c'est toi qui voit, hein...
JKB
Le Sun, 02 Oct 2011 15:14:52 +0200,
Aéris écrivait :
Le 02/10/2011 14:04, JKB a écrit :Quant aux attaques sur ssh, la
seule riposte fonctionnelle est un fail2ban avec un ssh sur mot de
passe non trivial (sauf peut-être dans le cas d'une attaque par un
réseau zombie lent de grande dimension).
Non, la véritable riposte est de désactiver les connexions p ar password
et d'autoriser uniquement celles par clefs RSA =)
Là , même avec un bruteforce, ils sont mal barrés (1024 ou 2048 bits)â¦
Et tu te retrouves dans la situation suivante (arrivée chez un
client) : ta clef oubliée sur une machine compromise ! Là , t u es bon
pour te rappeler tous les emplacements de ta fameuse clef et
surtout en te dépêchant ! Je préfère pour ma part un bon mot de passe Ã
une clef qui se balade sur une clef USB (voire par mail comme j'ai dà ©jÃ
vu). Enfin, c'est toi qui voit, hein...
JKB