detection de buffer overflow sur des services reseaux
7 réponses
Sylvain Eche
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en
réseau en ouvrant plein de ports.
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement. Ca ressemble fortement a des soucis de buffer overflow sur
les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux
aller plus loin et essayer d'identifier le buffer overflow comment m'y
prendre ?
je vois 2 approches : en analysant le comportement de l'Appli :
peut être essayer de la faire tourner dans une sorte machine virtuelle
ou un truc du genre qui détecte en temps réel le buffer overflow, les
données qui l'ont causé etc ...
Ou alors un analyseur de code statique binaire qui arriverait a détecter
les séquences assembleur dangereuses ?
L'autre approche, dans l'hypothèse ou je n'ai pas accès à l'application,
y a t'il des softs de stress de service réseaux qui pourrait analyser le
protocole de communication et tenter des buffers overflow dessus. Je
doute que l'approche telnet + envoie de AAAAA avec un A de plus à chaque
tentative soit suffisament exhaustive.
j'ai rapidement jeté un coup d'oeil à Protos pour valider un equipement
VOIP avec SIP. Yaurait t'il une approche générique
Kkes noms de softs sur le sujets m'interesseraient aussi
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le désassemblage de la zone et l'analyse de la pile peut éventuellement donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources, car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui injectant des lignes de commande très longues paramétrables, mais pour un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu de boulot pour tout packager. Ou encore regarder de près les logs d'un Linux compilé avec grsecurity (avec protection de pile activée) pour les attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en cas d'erreur <http://www.research.avayalabs.com/project/libsafe/>
Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement. Ca ressemble fortement a des soucis de buffer overflow sur
les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le
désassemblage de la zone et l'analyse de la pile peut éventuellement
donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux
aller plus loin et essayer d'identifier le buffer overflow comment m'y
prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources,
car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui
injectant des lignes de commande très longues paramétrables, mais pour
un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli :
peut être essayer de la faire tourner dans une sorte machine virtuelle
ou un truc du genre qui détecte en temps réel le buffer overflow, les
données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu
de boulot pour tout packager. Ou encore regarder de près les logs d'un
Linux compilé avec grsecurity (avec protection de pile activée) pour les
attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a détecter
les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de
fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en
cas d'erreur
<http://www.research.avayalabs.com/project/libsafe/>
Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le désassemblage de la zone et l'analyse de la pile peut éventuellement donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources, car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui injectant des lignes de commande très longues paramétrables, mais pour un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu de boulot pour tout packager. Ou encore regarder de près les logs d'un Linux compilé avec grsecurity (avec protection de pile activée) pour les attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en cas d'erreur <http://www.research.avayalabs.com/project/libsafe/>
Thierry Boudet
On 2005-06-21, Sylvain Eche wrote:
peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Regarde du coté de Valgrind, ça risque de marcher pour les overflows, je pense. En tout cas, c'est royal pour les leaks :)
http://www.valgrind.org/
-- _/°< coin
On 2005-06-21, Sylvain Eche <sylvaineche@free.fr> wrote:
peut être essayer de la faire tourner dans une sorte machine virtuelle
ou un truc du genre qui détecte en temps réel le buffer overflow, les
données qui l'ont causé etc ...
Regarde du coté de Valgrind, ça risque de marcher pour les
overflows, je pense. En tout cas, c'est royal pour les leaks :)
peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Regarde du coté de Valgrind, ça risque de marcher pour les overflows, je pense. En tout cas, c'est royal pour les leaks :)
http://www.valgrind.org/
-- _/°< coin
Manu
Sylvain Eche wrote:
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en réseau en ouvrant plein de ports. Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
Puisque personne ne propose cette solution, je me lance. Commence peut-être par déterminer qu'elle teste de Nessus fait planter l'appli avant de commencer du coté binaire.
Sylvain Eche wrote:
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en
réseau en ouvrant plein de ports.
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement. Ca ressemble fortement a des soucis de buffer overflow sur
les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux
aller plus loin et essayer d'identifier le buffer overflow comment m'y
prendre ?
Puisque personne ne propose cette solution, je me lance.
Commence peut-être par déterminer qu'elle teste de Nessus fait planter
l'appli avant de commencer du coté binaire.
je me suis retrouvé a auditer une appli propriétaire qui communique en réseau en ouvrant plein de ports. Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
Puisque personne ne propose cette solution, je me lance. Commence peut-être par déterminer qu'elle teste de Nessus fait planter l'appli avant de commencer du coté binaire.
Michel Arboi
On Tue Jun 21 2005 at 16:58, Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée complètement.
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance qu'un test à la fois.
Ca ressemble fortement a des soucis de buffer overflow
Pas forcément. Est-ce que tu testais en "safe checks" ou en normal ? Les connexions SSL initiées par find_service peuvent être redoutable contre les logiciels codés avec les pieds.
L'autre approche, dans l'hypothèse ou je n'ai pas accès à l'application, y a t'il des softs de stress de service réseaux qui pourrait analyser le protocole de communication et tenter des buffers overflow dessus.
Si Nessus a fait le coup, il n'y a pas à chercher bien loin. Ça peut être le simple port scan, ou bien les connexions SSL, ou les requêtes de reconnaissance de service (GET, HELP, etc), ou au final les dénis de services. Tu n'as pas dit si l'appli causait un protocole propriétaire. Si oui, il ne reste plus pas beaucoup d'autres suspects : misc_flood, qui balance 500 Ko de "X", line_overflow, qui envoie une ligne très longue, et éventuellement random_crap_DoS si tu as activé les tests "expérimentaux".
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement.
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance
qu'un test à la fois.
Ca ressemble fortement a des soucis de buffer overflow
Pas forcément. Est-ce que tu testais en "safe checks" ou en normal ?
Les connexions SSL initiées par find_service peuvent être redoutable
contre les logiciels codés avec les pieds.
L'autre approche, dans l'hypothèse ou je n'ai pas accès à
l'application, y a t'il des softs de stress de service réseaux qui
pourrait analyser le protocole de communication et tenter des buffers
overflow dessus.
Si Nessus a fait le coup, il n'y a pas à chercher bien loin.
Ça peut être le simple port scan, ou bien les connexions SSL, ou les
requêtes de reconnaissance de service (GET, HELP, etc), ou au final
les dénis de services.
Tu n'as pas dit si l'appli causait un protocole propriétaire.
Si oui, il ne reste plus pas beaucoup d'autres suspects :
misc_flood, qui balance 500 Ko de "X", line_overflow, qui envoie une
ligne très longue, et éventuellement random_crap_DoS si tu as activé
les tests "expérimentaux".
Un petit coup de nessus sur le poste et l'Appli est plantée complètement.
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance qu'un test à la fois.
Ca ressemble fortement a des soucis de buffer overflow
Pas forcément. Est-ce que tu testais en "safe checks" ou en normal ? Les connexions SSL initiées par find_service peuvent être redoutable contre les logiciels codés avec les pieds.
L'autre approche, dans l'hypothèse ou je n'ai pas accès à l'application, y a t'il des softs de stress de service réseaux qui pourrait analyser le protocole de communication et tenter des buffers overflow dessus.
Si Nessus a fait le coup, il n'y a pas à chercher bien loin. Ça peut être le simple port scan, ou bien les connexions SSL, ou les requêtes de reconnaissance de service (GET, HELP, etc), ou au final les dénis de services. Tu n'as pas dit si l'appli causait un protocole propriétaire. Si oui, il ne reste plus pas beaucoup d'autres suspects : misc_flood, qui balance 500 Ko de "X", line_overflow, qui envoie une ligne très longue, et éventuellement random_crap_DoS si tu as activé les tests "expérimentaux".
Pour info le soft en question tourne sous windows 2000. Et qui plus est il écoute au moins sur 6 ou 7 ports.
Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le désassemblage de la zone et l'analyse de la pile peut éventuellement donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources, car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui injectant des lignes de commande très longues paramétrables, mais pour un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu de boulot pour tout packager. Ou encore regarder de près les logs d'un Linux compilé avec grsecurity (avec protection de pile activée) pour les attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en cas d'erreur <http://www.research.avayalabs.com/project/libsafe/>
Pour info le soft en question tourne sous windows 2000.
Et qui plus est il écoute au moins sur 6 ou 7 ports.
Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement. Ca ressemble fortement a des soucis de buffer overflow
sur les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le
désassemblage de la zone et l'analyse de la pile peut éventuellement
donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux
aller plus loin et essayer d'identifier le buffer overflow comment m'y
prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources,
car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui
injectant des lignes de commande très longues paramétrables, mais pour
un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli :
peut être essayer de la faire tourner dans une sorte machine virtuelle
ou un truc du genre qui détecte en temps réel le buffer overflow, les
données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu
de boulot pour tout packager. Ou encore regarder de près les logs d'un
Linux compilé avec grsecurity (avec protection de pile activée) pour les
attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a
détecter les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de
fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en
cas d'erreur
<http://www.research.avayalabs.com/project/libsafe/>
Pour info le soft en question tourne sous windows 2000. Et qui plus est il écoute au moins sur 6 ou 7 ports.
Sylvain Eche wrote:
Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
Je support que vous travaillez sur environnement Unix/Linux.
L'appli en question a-t-elle généré un fichier core exploitable ? Le désassemblage de la zone et l'analyse de la pile peut éventuellement donner des infos (déja, le core indiquera quel process a crashé)
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
De manière générique, humm, bigre, ce n'est pas facile sans les sources, car vous pouvez très bien passer à côté d'un scénario "très peu probable".
Des systèmes comme BFBTester permettent de stresser un binaire en lui injectant des lignes de commande très longues paramétrables, mais pour un service réseau ce n'est pas aussi simple.
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ...
Ou lancer tous les processus sous debugger, ce qui peut demander un peu de boulot pour tout packager. Ou encore regarder de près les logs d'un Linux compilé avec grsecurity (avec protection de pile activée) pour les attaques type execution de code sur la pile
Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
Autre piste: libsafe, qui permet d'encapsuler un certain nombre de fonctions (strcpy, strcat, gets, ..) et logge/termine le programme en cas d'erreur <http://www.research.avayalabs.com/project/libsafe/>
Ascadix
Tapotant joyeusement sur son clavier, Sylvain Eche à lancé dans le tuyaux les octets que voici : <news:42b8269b$0$3222$
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en réseau en ouvrant plein de ports. Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ... Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
L'autre approche, dans l'hypothèse ou je n'ai pas accès à l'application, y a t'il des softs de stress de service réseaux qui pourrait analyser le protocole de communication et tenter des buffers overflow dessus. Je doute que l'approche telnet + envoie de AAAAA avec un A de plus à chaque tentative soit suffisament exhaustive. j'ai rapidement jeté un coup d'oeil à Protos pour valider un equipement VOIP avec SIP. Yaurait t'il une approche générique
Kkes noms de softs sur le sujets m'interesseraient aussi
merci
Vu que c'est une applis windows, ça donne quoi monté sur un XP SP2 avec le DEP activé ? est-ce que le DEP ferme l'appli dés qu'elle démare ? ou la ferme-t-il quand tu commence à taper dessus ave Nessus ?
L'idée suivante, c'est de voir ce qu'on peut tirer comme info de DEP quand il ferme une applis ...mais là j'ai zéro info, qqun à des billes là-dessus ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Tapotant joyeusement sur son clavier, Sylvain Eche à lancé dans le tuyaux
les octets que voici :
<news:42b8269b$0$3222$626a14ce@news.free.fr>
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en
réseau en ouvrant plein de ports.
Un petit coup de nessus sur le poste et l'Appli est plantée
complètement. Ca ressemble fortement a des soucis de buffer overflow
sur les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux
aller plus loin et essayer d'identifier le buffer overflow comment m'y
prendre ?
je vois 2 approches : en analysant le comportement de l'Appli :
peut être essayer de la faire tourner dans une sorte machine virtuelle
ou un truc du genre qui détecte en temps réel le buffer overflow, les
données qui l'ont causé etc ...
Ou alors un analyseur de code statique binaire qui arriverait a
détecter les séquences assembleur dangereuses ?
L'autre approche, dans l'hypothèse ou je n'ai pas accès à
l'application, y a t'il des softs de stress de service réseaux qui
pourrait analyser le protocole de communication et tenter des buffers
overflow dessus. Je doute que l'approche telnet + envoie de AAAAA
avec un A de plus à chaque tentative soit suffisament exhaustive.
j'ai rapidement jeté un coup d'oeil à Protos pour valider un
equipement VOIP avec SIP. Yaurait t'il une approche générique
Kkes noms de softs sur le sujets m'interesseraient aussi
merci
Vu que c'est une applis windows, ça donne quoi monté sur un XP SP2 avec le
DEP activé ?
est-ce que le DEP ferme l'appli dés qu'elle démare ? ou la ferme-t-il quand
tu commence à taper dessus ave Nessus ?
L'idée suivante, c'est de voir ce qu'on peut tirer comme info de DEP quand
il ferme une applis ...mais là j'ai zéro info, qqun à des billes là-dessus ?
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Tapotant joyeusement sur son clavier, Sylvain Eche à lancé dans le tuyaux les octets que voici : <news:42b8269b$0$3222$
Bonjour
je me suis retrouvé a auditer une appli propriétaire qui communique en réseau en ouvrant plein de ports. Un petit coup de nessus sur le poste et l'Appli est plantée complètement. Ca ressemble fortement a des soucis de buffer overflow sur les services réseaux de l'application.
N'etant pas un pro du Buffer Overflow, Ma question est : si je veux aller plus loin et essayer d'identifier le buffer overflow comment m'y prendre ?
je vois 2 approches : en analysant le comportement de l'Appli : peut être essayer de la faire tourner dans une sorte machine virtuelle ou un truc du genre qui détecte en temps réel le buffer overflow, les données qui l'ont causé etc ... Ou alors un analyseur de code statique binaire qui arriverait a détecter les séquences assembleur dangereuses ?
L'autre approche, dans l'hypothèse ou je n'ai pas accès à l'application, y a t'il des softs de stress de service réseaux qui pourrait analyser le protocole de communication et tenter des buffers overflow dessus. Je doute que l'approche telnet + envoie de AAAAA avec un A de plus à chaque tentative soit suffisament exhaustive. j'ai rapidement jeté un coup d'oeil à Protos pour valider un equipement VOIP avec SIP. Yaurait t'il une approche générique
Kkes noms de softs sur le sujets m'interesseraient aussi
merci
Vu que c'est une applis windows, ça donne quoi monté sur un XP SP2 avec le DEP activé ? est-ce que le DEP ferme l'appli dés qu'elle démare ? ou la ferme-t-il quand tu commence à taper dessus ave Nessus ?
L'idée suivante, c'est de voir ce qu'on peut tirer comme info de DEP quand il ferme une applis ...mais là j'ai zéro info, qqun à des billes là-dessus ?
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Michel Arboi
On Wed Jun 29 2005 at 17:24, Nicob wrote:
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance qu'un test à la fois.
Vu que ce n'est pas la solution plus simple pour un utilisateur "de base" de Nessus (faut passer en ligne de commande ou cliquouiller à tout va),
Ça n'a rien de sorcier, il suffit d'entrer "1" dans le champ "max check" dans l'onglet qui regroupe les options de scan, les ports scanners et la plage de ports.
il peut être préférable de sniffer le trafic généré par le scan
Ce n'est pas incompatible. Ne lancer qu'un test à la fois évite de devoir éplucher un plat de nouilles.
On Wed Jun 29 2005 at 17:24, Nicob wrote:
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance qu'un
test à la fois.
Vu que ce n'est pas la solution plus simple pour un utilisateur "de base"
de Nessus (faut passer en ligne de commande ou cliquouiller à tout va),
Ça n'a rien de sorcier, il suffit d'entrer "1" dans le champ "max
check" dans l'onglet qui regroupe les options de scan, les ports
scanners et la plage de ports.
il peut être préférable de sniffer le trafic généré par le scan
Ce n'est pas incompatible. Ne lancer qu'un test à la fois évite de
devoir éplucher un plat de nouilles.
Essaie de déterminer quel test plante l'appli. Au besoin, ne lance qu'un test à la fois.
Vu que ce n'est pas la solution plus simple pour un utilisateur "de base" de Nessus (faut passer en ligne de commande ou cliquouiller à tout va),
Ça n'a rien de sorcier, il suffit d'entrer "1" dans le champ "max check" dans l'onglet qui regroupe les options de scan, les ports scanners et la plage de ports.
il peut être préférable de sniffer le trafic généré par le scan
Ce n'est pas incompatible. Ne lancer qu'un test à la fois évite de devoir éplucher un plat de nouilles.
