je fais tourner une debian que je protère entre autre avec iptables.
cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
nmap le confirme.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
J'ai également essayer d'installer Portsentry. Il tourne et écoute sur
certains ports. Puis je fais un scan de ports avec nmap, et la aucune action
n'est prise par portsentry.
Quelqu un a t il reussi a configurer cette application sous debian. Il
s'agit de la version 1.2.0 sous sarge 3.1
On Tue, 29 May 2007 15:44:34 +0200, "fabrice" wrote:
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui, et ? Vous espérez qu'en dissimulant explicitement vos failles personne ne les exploitera ? -- Nina
octane
On 29 mai, 15:44, "fabrice" wrote:
Bonjour à tous,
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne et écoute sur certains ports. Puis je fais un scan de ports avec nmap, et la aucune action n'est prise par portsentry. Quelqu un a t il reussi a configurer cette application sous debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere generale.
On 29 mai, 15:44, "fabrice" <emouc...@test.com> wrote:
Bonjour à tous,
je fais tourner une debian que je protère entre autre avec iptables.
cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole,
abominable à firewaller et qui fait transiter les mots de passe
en clair. Scp est recent, sur, fiable et il existe pleins de
clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne
et écoute sur certains ports. Puis je fais un scan de ports
avec nmap, et la aucune action n'est prise par portsentry.
Quelqu un a t il reussi a configurer cette application sous
debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere
generale.
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne et écoute sur certains ports. Puis je fais un scan de ports avec nmap, et la aucune action n'est prise par portsentry. Quelqu un a t il reussi a configurer cette application sous debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere generale.
Arol
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
Surtout qu'il y a rien à installer (le sshd est déjà installé) et pour la gestion des comptes, il y a rien à faire non plus.
En fait, les gros avantages du ftp sont (à mon avis) : - non crypté, donc faible charge cpu - ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole,
abominable à firewaller et qui fait transiter les mots de passe
en clair. Scp est recent, sur, fiable et il existe pleins de
clients sur toutes les plateformes pour interagir avec.
Surtout qu'il y a rien à installer (le sshd est déjà installé) et pour la
gestion des comptes, il y a rien à faire non plus.
En fait, les gros avantages du ftp sont (à mon avis) :
- non crypté, donc faible charge cpu
- ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
Surtout qu'il y a rien à installer (le sshd est déjà installé) et pour la gestion des comptes, il y a rien à faire non plus.
En fait, les gros avantages du ftp sont (à mon avis) : - non crypté, donc faible charge cpu - ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Nicolas George
"Arol" wrote in message <465c36b3$0$10442$:
- ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Pas complètement évident. Si tu as un serveur de mail configuré pour invoquer procmail, par exemple, on peut faire des trucs rigolos rien qu'en uploadant des fichiers.
"Arol" wrote in message <465c36b3$0$10442$426a74cc@news.free.fr>:
- ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Pas complètement évident. Si tu as un serveur de mail configuré pour
invoquer procmail, par exemple, on peut faire des trucs rigolos rien qu'en
uploadant des fichiers.
- ne permet rien d'autre que du ul/dl, ça permet de sécuriser un compte.
Pas complètement évident. Si tu as un serveur de mail configuré pour invoquer procmail, par exemple, on peut faire des trucs rigolos rien qu'en uploadant des fichiers.
fabrice
Je ne vois pas le rapport avec ma question. Il s'agit d'une interrogation technique. Et je désire cacher le figerprint de l'OS. Je n'ai jamais parlé de camoufler mes failles comme vous dîtes. C'est un élèment supplémentaire. Je trouve génant qu'un scan via nmap remonte ces informations.
bonne soirée
"Nina Popravka" a écrit dans le message de news:
On Tue, 29 May 2007 15:44:34 +0200, "fabrice" wrote:
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui, et ? Vous espérez qu'en dissimulant explicitement vos failles personne ne les exploitera ? -- Nina
Je ne vois pas le rapport avec ma question. Il s'agit d'une interrogation
technique.
Et je désire cacher le figerprint de l'OS.
Je n'ai jamais parlé de camoufler mes failles comme vous dîtes. C'est un
élèment supplémentaire.
Je trouve génant qu'un scan via nmap remonte ces informations.
bonne soirée
"Nina Popravka" <Nina@nospam.invalid> a écrit dans le message de news:
qsbo5316nr4bd2mo96vov5qn7frr3idss8@4ax.com...
On Tue, 29 May 2007 15:44:34 +0200, "fabrice" <emouchet@test.com>
wrote:
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Oui, et ?
Vous espérez qu'en dissimulant explicitement vos failles personne ne
les exploitera ?
--
Nina
Je ne vois pas le rapport avec ma question. Il s'agit d'une interrogation technique. Et je désire cacher le figerprint de l'OS. Je n'ai jamais parlé de camoufler mes failles comme vous dîtes. C'est un élèment supplémentaire. Je trouve génant qu'un scan via nmap remonte ces informations.
bonne soirée
"Nina Popravka" a écrit dans le message de news:
On Tue, 29 May 2007 15:44:34 +0200, "fabrice" wrote:
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui, et ? Vous espérez qu'en dissimulant explicitement vos failles personne ne les exploitera ? -- Nina
fabrice
Parfois l'universalité est préférable. Le service en question repose sur une couche SSL. Donc pas de transfert de data/password en clair. fabrice.
a écrit dans le message de news:
On 29 mai, 15:44, "fabrice" wrote:
Bonjour à tous,
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne et écoute sur certains ports. Puis je fais un scan de ports avec nmap, et la aucune action n'est prise par portsentry. Quelqu un a t il reussi a configurer cette application sous debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere generale.
Parfois l'universalité est préférable.
Le service en question repose sur une couche SSL. Donc pas de transfert de
data/password en clair.
fabrice.
<octane@alinto.com> a écrit dans le message de news:
1180446781.709479.126300@q69g2000hsb.googlegroups.com...
On 29 mai, 15:44, "fabrice" <emouc...@test.com> wrote:
Bonjour à tous,
je fais tourner une debian que je protère entre autre avec iptables.
cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole,
abominable à firewaller et qui fait transiter les mots de passe
en clair. Scp est recent, sur, fiable et il existe pleins de
clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne
et écoute sur certains ports. Puis je fais un scan de ports
avec nmap, et la aucune action n'est prise par portsentry.
Quelqu un a t il reussi a configurer cette application sous
debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere
generale.
Parfois l'universalité est préférable. Le service en question repose sur une couche SSL. Donc pas de transfert de data/password en clair. fabrice.
a écrit dans le message de news:
On 29 mai, 15:44, "fabrice" wrote:
Bonjour à tous,
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
Mais pourquoi ne pas utiliser scp et sftp? ftp est un vieux protocole, abominable à firewaller et qui fait transiter les mots de passe en clair. Scp est recent, sur, fiable et il existe pleins de clients sur toutes les plateformes pour interagir avec.
nmap le confirme.
Ok.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Oui
Existet il un moyen de bloquer ces informations de type fingerprinting ?
pourquoi?
J'ai également essayer d'installer Portsentry. Il tourne et écoute sur certains ports. Puis je fais un scan de ports avec nmap, et la aucune action n'est prise par portsentry. Quelqu un a t il reussi a configurer cette application sous debian. Il s'agit de la version 1.2.0 sous sarge 3.1
portsentry doit ecouter les ports. S'ils sont bloques par
iptables, portsentry ne verra aucune requete et n'agira pas.
A mon avis, portsentry est une mauvaise solution, de maniere generale.
Thierry Boudet
On 2007-05-29, fabrice wrote:
Et je désire cacher le figerprint de l'OS.
On trouve beaucoup d'informations sur ce sujet dans le grand Ternet et dans la doc de nmap lui-même. /usr/share/doc/nmap/nmap-fingerprinting-article.txt.gz
Je trouve génant qu'un scan via nmap remonte ces informations.
Ne pas untiliser nmap, alors...
bonne soirée
Merci de troller à l'endroit.
-- A horse will do most of its maintenace itself, but it needs fuel even if you're not using it.
On 2007-05-29, fabrice <emouchet@test.com> wrote:
Et je désire cacher le figerprint de l'OS.
On trouve beaucoup d'informations sur ce sujet dans le
grand Ternet et dans la doc de nmap lui-même.
/usr/share/doc/nmap/nmap-fingerprinting-article.txt.gz
Je trouve génant qu'un scan via nmap remonte ces informations.
Ne pas untiliser nmap, alors...
bonne soirée
Merci de troller à l'endroit.
--
A horse will do most of its maintenace itself, but it needs fuel even if
you're not using it.
On trouve beaucoup d'informations sur ce sujet dans le grand Ternet et dans la doc de nmap lui-même. /usr/share/doc/nmap/nmap-fingerprinting-article.txt.gz
Je trouve génant qu'un scan via nmap remonte ces informations.
Ne pas untiliser nmap, alors...
bonne soirée
Merci de troller à l'endroit.
-- A horse will do most of its maintenace itself, but it needs fuel even if you're not using it.
Nina Popravka
On Tue, 29 May 2007 16:33:01 +0200, "fabrice" wrote:
Je trouve génant qu'un scan via nmap remonte ces informations.
Et je trouve ça parfaitement ridicule d'en être gêné. Bonne soirée aussi. -- Nina
On Tue, 29 May 2007 16:33:01 +0200, "fabrice" <emouchet@test.com>
wrote:
Je trouve génant qu'un scan via nmap remonte ces informations.
Et je trouve ça parfaitement ridicule d'en être gêné.
Bonne soirée aussi.
--
Nina
On Tue, 29 May 2007 16:33:01 +0200, "fabrice" wrote:
Je trouve génant qu'un scan via nmap remonte ces informations.
Et je trouve ça parfaitement ridicule d'en être gêné. Bonne soirée aussi. -- Nina
Mihamina (R12y) Rakotomandimby
fabrice - <f3hao2$eds$ :
Bonjour à tous,
Bonjour,
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert. nmap le confirme. Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
Bon, je m'y mets aussi: D'abord, on répond en dessous et non par dessus, comme tu fais. Ensuite, la sécurité par l'obscurité, c'est mal. Ce n'est certainement pas comme ça que les OS réputés sûrs le sont devenus. Enfin, un peu de lecture: http://www.google.com/search?q=securite+par+l%27obscurite
fabrice - <f3hao2$eds$1@s1.news.oleane.net> :
Bonjour à tous,
Bonjour,
je fais tourner une debian que je protère entre autre avec iptables.
cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
nmap le confirme.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
Bon, je m'y mets aussi:
D'abord, on répond en dessous et non par dessus, comme tu fais.
Ensuite, la sécurité par l'obscurité, c'est mal. Ce n'est certainement pas
comme ça que les OS réputés sûrs le sont devenus.
Enfin, un peu de lecture:
http://www.google.com/search?q=securite+par+l%27obscurite
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert. nmap le confirme. Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
Bon, je m'y mets aussi: D'abord, on répond en dessous et non par dessus, comme tu fais. Ensuite, la sécurité par l'obscurité, c'est mal. Ce n'est certainement pas comme ça que les OS réputés sûrs le sont devenus. Enfin, un peu de lecture: http://www.google.com/search?q=securite+par+l%27obscurite
Pascal Hambourg
Salut,
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert. nmap le confirme.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
La détection de l'uptime peut être contrée en désactivant les timestamps TCP (/proc/sys/net/ipv4/tcp_timestamps=0), mais ça aurait une incidence sur le nombre de connexions TCP sortantes possibles simultanément.
Pour le reste, la correspondance 'recent' d'iptables peut aider à détecter et/ou bloquer les adresses sources dépassant un certain nombre de connexions par unité de temps.
Salut,
je fais tourner une debian que je protère entre autre avec iptables.
cette machine fait tourner un serveur ftp, et ce seul port est ouvert.
nmap le confirme.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup
d'informations sur l'OS.
Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
La détection de l'uptime peut être contrée en désactivant les timestamps
TCP (/proc/sys/net/ipv4/tcp_timestamps=0), mais ça aurait une incidence
sur le nombre de connexions TCP sortantes possibles simultanément.
Pour le reste, la correspondance 'recent' d'iptables peut aider à
détecter et/ou bloquer les adresses sources dépassant un certain nombre
de connexions par unité de temps.
je fais tourner une debian que je protère entre autre avec iptables. cette machine fait tourner un serveur ftp, et ce seul port est ouvert. nmap le confirme.
Mais je m'aperçois avec chagrin qu'il retourne également beaucoup d'informations sur l'OS. Version, Kernel, Uptime ...
Existet il un moyen de bloquer ces informations de type fingerprinting ?
La détection de l'uptime peut être contrée en désactivant les timestamps TCP (/proc/sys/net/ipv4/tcp_timestamps=0), mais ça aurait une incidence sur le nombre de connexions TCP sortantes possibles simultanément.
Pour le reste, la correspondance 'recent' d'iptables peut aider à détecter et/ou bloquer les adresses sources dépassant un certain nombre de connexions par unité de temps.
