comment bloquer les intrusitons netcat sous windows?
42 réponses
Franck Danard
La question est dan le sujet :)
En fait j'ai un serveur apache + Mysql sur windows, sur ma station je met à
jour dyndns.org pour avoir un URL perso.
Ma station comporte ZA (fire wall) et deux antivirus, bitdefender et McAfee.
Bitdefender a détecté nc.exe à deux reprises. j'ai du supprimer la mise à
jour de dyndns pour éviter que le pleutre rentre encore un fois foutre sa
merde dans mon LAN!
Plus de nc.exe (Netcat) à ce jour.
Le problème c'est que le mode opératoire pour hacker un serveur semble très
facile (un script qui dépose netcat sur le serveur puis par telnet on fait
tout ce que l'on veut!)
Que faut-il activer au niveau de la sécurité reseau pour bloquer
l'installation de netcat?
plus de détaille sur netcat :
http://www.easyprogs.com/index.php?callPage=./Divers/CouteauxSuisses/batchRecupCodeSourceHTML.php
Ious les tests d'intrusion réalisés en externe et en aveugle sur un SI mettent les testeurs dans la peau de pirates informatiques & ils agissent en simulant le comportement de personnes malveillantes.
Je ne suis pas vraiment d'accord.
On va voir. ;)
Un périmètre est défini avant le test
Ici je parle d'un test de sécurité externe en aveugle.
et tu dois rester dans ce périmètre si d'une part tu veux être en accord avec ce que te demande le client
C'est le client qui précise le contexte & le périmètre de l'intervention du prestataire qui va réaliser le test d'intrusion autrement dit test de sécurité.
et d'autre part être dans une situation plus ou moins légale.
La cadre est complétement légal étant donné que c'est le client (propriétaire du SI) qui engage un prestataire pour tester la sécurité de son SI.
Le pirate lui a un périmètre plus vaste :-)
Le pirate n'a pas de limites et encore moins de déontologie alors que le(s) testeur(s) si. Pour résumé un pirate va tout faire pour atteindre sa cible. Alors que le testeur devra s'arrêter si l'environnement dans lequel il progresse n'est plus celui de son client. Ok ?
Typiquement, si tu veux attaquer un serveur web hébergé chez un hébergeur, tu ne pourras pas passer par la machine trouée d'à coté... ou l'appli co-hébergée, alors que le pirate lui pourra trouver ça plus simple.
La problématique de la propriété des infrastructures est du ressort du testeur. Il doit savoir et surtout vérifier où il met les pieds avant de poursuivre sa campagne.
Enfin, les pentesteurs vont montrer un certain nombre de trous, exploitables ou exploités, peuvent parfois montrer qu'une machine est compromise, mais leur tâche s'arrête souvent là.
Pas d'accord le rapport doit contenir toutes les observations constatées accompagnées des recommendations qui s'imposent. Après si le client ne les applique/suit pas (et ça arrive malheureusement) c'est son problème.
On sait qu'il y a des trous, on sait comment certains trous ont été utilisés, quant à en faire une généralité, cela me semble difficile.
Je ne comprends pas ton raisonnement ici. Tu fais un gros raccourci sans fournir d'explications. Peux-tu expliciter pourquoi certaines observations ne peuvent donner lieu à des généralités ?
Un bon plan à mon avis pour avoir une vision assez panoramique est de bosser dans la cellule audit d'un grand compte, là il doit y avoir des choses à voir, et de façon globale, même si cela reste propre à une entité.
Oui. Mais amha travailler avec de grandes entités (privées ou publique) disposant de SI important offrent aussi une bonne vision. C'est pourquoi je notais que les sociétés spécialisées en audits technique notamment tests d'intrusion devraient publier des études en ce sens.
On 28 Feb 2005 18:23:14 GMT, Eric Lalitte <eric@lalitte.com> wrote:
Ious les tests d'intrusion réalisés en externe et en aveugle sur un SI
mettent les testeurs dans la peau de pirates informatiques & ils
agissent en simulant le comportement de personnes malveillantes.
Je ne suis pas vraiment d'accord.
On va voir. ;)
Un périmètre est défini avant le test
Ici je parle d'un test de sécurité externe en aveugle.
et tu dois rester dans ce périmètre si d'une part tu veux être en accord
avec ce que te demande le client
C'est le client qui précise le contexte & le périmètre de l'intervention
du prestataire qui va réaliser le test d'intrusion autrement dit test de
sécurité.
et d'autre part être dans une situation plus ou moins légale.
La cadre est complétement légal étant donné que c'est le client
(propriétaire du SI) qui engage un prestataire pour tester la sécurité de
son SI.
Le pirate lui a un périmètre plus vaste :-)
Le pirate n'a pas de limites et encore moins de déontologie alors que
le(s) testeur(s) si.
Pour résumé un pirate va tout faire pour atteindre sa cible.
Alors que le testeur devra s'arrêter si l'environnement dans lequel il
progresse n'est plus celui de son client. Ok ?
Typiquement, si tu veux attaquer un serveur web hébergé chez un
hébergeur, tu ne pourras pas passer par la machine trouée d'à coté... ou
l'appli co-hébergée, alors que le pirate lui pourra trouver ça plus
simple.
La problématique de la propriété des infrastructures est du ressort du
testeur. Il doit savoir et surtout vérifier où il met les pieds avant de
poursuivre sa campagne.
Enfin, les pentesteurs vont montrer un certain nombre de trous,
exploitables ou exploités, peuvent parfois montrer qu'une machine est
compromise, mais leur tâche s'arrête souvent là.
Pas d'accord le rapport doit contenir toutes les observations constatées
accompagnées des recommendations qui s'imposent. Après si le client ne les
applique/suit pas (et ça arrive malheureusement) c'est son problème.
On sait qu'il y a des trous, on sait comment certains trous ont été
utilisés, quant à en faire une généralité, cela me semble difficile.
Je ne comprends pas ton raisonnement ici. Tu fais un gros raccourci sans
fournir d'explications. Peux-tu expliciter pourquoi certaines observations
ne peuvent donner lieu à des généralités ?
Un bon plan à mon avis pour avoir une vision assez panoramique est de
bosser dans la cellule audit d'un grand compte, là il doit y avoir des
choses à voir, et de façon globale, même si cela reste propre à une
entité.
Oui.
Mais amha travailler avec de grandes entités (privées ou publique)
disposant de SI important offrent aussi une bonne vision. C'est pourquoi
je notais que les sociétés spécialisées en audits technique notamment
tests d'intrusion devraient publier des études en ce sens.
Ious les tests d'intrusion réalisés en externe et en aveugle sur un SI mettent les testeurs dans la peau de pirates informatiques & ils agissent en simulant le comportement de personnes malveillantes.
Je ne suis pas vraiment d'accord.
On va voir. ;)
Un périmètre est défini avant le test
Ici je parle d'un test de sécurité externe en aveugle.
et tu dois rester dans ce périmètre si d'une part tu veux être en accord avec ce que te demande le client
C'est le client qui précise le contexte & le périmètre de l'intervention du prestataire qui va réaliser le test d'intrusion autrement dit test de sécurité.
et d'autre part être dans une situation plus ou moins légale.
La cadre est complétement légal étant donné que c'est le client (propriétaire du SI) qui engage un prestataire pour tester la sécurité de son SI.
Le pirate lui a un périmètre plus vaste :-)
Le pirate n'a pas de limites et encore moins de déontologie alors que le(s) testeur(s) si. Pour résumé un pirate va tout faire pour atteindre sa cible. Alors que le testeur devra s'arrêter si l'environnement dans lequel il progresse n'est plus celui de son client. Ok ?
Typiquement, si tu veux attaquer un serveur web hébergé chez un hébergeur, tu ne pourras pas passer par la machine trouée d'à coté... ou l'appli co-hébergée, alors que le pirate lui pourra trouver ça plus simple.
La problématique de la propriété des infrastructures est du ressort du testeur. Il doit savoir et surtout vérifier où il met les pieds avant de poursuivre sa campagne.
Enfin, les pentesteurs vont montrer un certain nombre de trous, exploitables ou exploités, peuvent parfois montrer qu'une machine est compromise, mais leur tâche s'arrête souvent là.
Pas d'accord le rapport doit contenir toutes les observations constatées accompagnées des recommendations qui s'imposent. Après si le client ne les applique/suit pas (et ça arrive malheureusement) c'est son problème.
On sait qu'il y a des trous, on sait comment certains trous ont été utilisés, quant à en faire une généralité, cela me semble difficile.
Je ne comprends pas ton raisonnement ici. Tu fais un gros raccourci sans fournir d'explications. Peux-tu expliciter pourquoi certaines observations ne peuvent donner lieu à des généralités ?
Un bon plan à mon avis pour avoir une vision assez panoramique est de bosser dans la cellule audit d'un grand compte, là il doit y avoir des choses à voir, et de façon globale, même si cela reste propre à une entité.
Oui. Mais amha travailler avec de grandes entités (privées ou publique) disposant de SI important offrent aussi une bonne vision. C'est pourquoi je notais que les sociétés spécialisées en audits technique notamment tests d'intrusion devraient publier des études en ce sens.
Gros-Bibi
J'ai du mal m'exprimer. Je voulais dire : Sous linux, la commande wget aurait permis le téléchargement distant du serveur netcat. Ne connaissant pas d'équivalent (en standart) sous windows, je me demandais comment le faire. Car la difficulté réside justement dans le fait d'obliger la cible à acquérir le serveur. Mais nicob semblait cependant avoir trouvé une solution efficace pour windows par la création d'un vbs puis son exécution.
J'ai du mal m'exprimer.
Je voulais dire :
Sous linux, la commande wget aurait permis le téléchargement distant du
serveur netcat.
Ne connaissant pas d'équivalent (en standart) sous windows, je me demandais
comment le faire.
Car la difficulté réside justement dans le fait d'obliger la cible à
acquérir le serveur.
Mais nicob semblait cependant avoir trouvé une solution efficace pour
windows par la création d'un vbs puis son exécution.
J'ai du mal m'exprimer. Je voulais dire : Sous linux, la commande wget aurait permis le téléchargement distant du serveur netcat. Ne connaissant pas d'équivalent (en standart) sous windows, je me demandais comment le faire. Car la difficulté réside justement dans le fait d'obliger la cible à acquérir le serveur. Mais nicob semblait cependant avoir trouvé une solution efficace pour windows par la création d'un vbs puis son exécution.
