Dans le message <news:8sCvd.98211$,
*françois* tapota sur f.c.o.l.configuration :sshd(2)_config==> les mots clé DenyHosts et AllowHosts sont fait pour ça,
Ces options ne sont pas disponibles dans OpenSSH, la version du serveur
SSH généralement installée dans les grandes distributions, mais
seulement dans la version gratuite du serveur SSH commercial.
utilisé conjointement, c'est trés efficace, ils autorisent ou
empêchent les connexions des machines distantes, ip ou nom de
machines, tu peux mettre des jokers "*" ou "?", ce qui évite de passer
par (s)host.deny et (s)host.allow qui sont facilement "détournable".
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans le message <news:8sCvd.98211$ha.83993@news.chello.at>,
*françois* tapota sur f.c.o.l.configuration :
sshd(2)_config==> les mots clé DenyHosts et AllowHosts sont fait pour ça,
Ces options ne sont pas disponibles dans OpenSSH, la version du serveur
SSH généralement installée dans les grandes distributions, mais
seulement dans la version gratuite du serveur SSH commercial.
utilisé conjointement, c'est trés efficace, ils autorisent ou
empêchent les connexions des machines distantes, ip ou nom de
machines, tu peux mettre des jokers "*" ou "?", ce qui évite de passer
par (s)host.deny et (s)host.allow qui sont facilement "détournable".
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans le message <news:8sCvd.98211$,
*françois* tapota sur f.c.o.l.configuration :sshd(2)_config==> les mots clé DenyHosts et AllowHosts sont fait pour ça,
Ces options ne sont pas disponibles dans OpenSSH, la version du serveur
SSH généralement installée dans les grandes distributions, mais
seulement dans la version gratuite du serveur SSH commercial.
utilisé conjointement, c'est trés efficace, ils autorisent ou
empêchent les connexions des machines distantes, ip ou nom de
machines, tu peux mettre des jokers "*" ou "?", ce qui évite de passer
par (s)host.deny et (s)host.allow qui sont facilement "détournable".
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.
Tu préconises dans un autre poste d'utiliser iptable, il va sans dire que
c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
(on va dire que j'ai un petit routeur genre pII),
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.
Tu préconises dans un autre poste d'utiliser iptable, il va sans dire que
c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
(on va dire que j'ai un petit routeur genre pII),
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.
Tu préconises dans un autre poste d'utiliser iptable, il va sans dire que
c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
(on va dire que j'ai un petit routeur genre pII),
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
Dans le message <news:E1Nvd.101804$,
*françois* tapota sur f.c.o.l.configuration :Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.Tu préconises dans un autre poste d'utiliser iptable, il va sans dire
que c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
Les ressources consommées par Netfilter sont très négligeable si on les
compare avec les ressources utilisées par le filtrage d'un logiciel.
(on va dire que j'ai un petit routeur genre pII),
C'est amplement suffisant ! Un routeur avec de nombreuses règles
iptables/Netfilter tourne sans soucis sur un 486.
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
La restriction se fait au niveau de l'authentification.
Cela n'empêche
donc pas les attaques du type brute force qui pourraient venir
d'adresses IP inconnues.
Dans le message <news:E1Nvd.101804$ha.28036@news.chello.at>,
*françois* tapota sur f.c.o.l.configuration :
Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.
Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.
Tu préconises dans un autre poste d'utiliser iptable, il va sans dire
que c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
Les ressources consommées par Netfilter sont très négligeable si on les
compare avec les ressources utilisées par le filtrage d'un logiciel.
(on va dire que j'ai un petit routeur genre pII),
C'est amplement suffisant ! Un routeur avec de nombreuses règles
iptables/Netfilter tourne sans soucis sur un 486.
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
La restriction se fait au niveau de l'authentification.
Cela n'empêche
donc pas les attaques du type brute force qui pourraient venir
d'adresses IP inconnues.
Dans le message <news:E1Nvd.101804$,
*françois* tapota sur f.c.o.l.configuration :Les directives AllowHosts et DenyHosts ou les fichiers hosts.deny et
hosts.allow utilisent le même mécanisme, c'est-à-dire tcp-wrappers.
L'efficacité reste la même.Dans ce cas là l'utilisation des directives Allow(Deny)Users devient
obligatoire (à moins d'utiliser iptable), à la poubelle tcp-wrapper.Tu préconises dans un autre poste d'utiliser iptable, il va sans dire
que c'est trés efficace et facilement configurable, mais cela n'entraine
pas une consomation des ressources pour rien ?
Les ressources consommées par Netfilter sont très négligeable si on les
compare avec les ressources utilisées par le filtrage d'un logiciel.
(on va dire que j'ai un petit routeur genre pII),
C'est amplement suffisant ! Un routeur avec de nombreuses règles
iptables/Netfilter tourne sans soucis sur un 486.
vu qu'on peux restreindre l'accès par le fichier de conf d'OpenSSH
directement, cela fait toujours une "couche" en moins à passer.
La restriction se fait au niveau de l'authentification.
Cela n'empêche
donc pas les attaques du type brute force qui pourraient venir
d'adresses IP inconnues.