avec quels outils on peut scanner les ports efficacement sous mac os x
svp ? :-)
avec l'utilitaire de réseau c'est super long, il est lancé depuis plus
de 24h et il y est encore ...
est ce que c'est possible de scanner les ports udp aussi ?
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
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
Hugolino
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
bonjour :-)
Bonjour,
avec quels outils on peut scanner les ports efficacement sous mac os x svp ? :-)
Je ne connais pas Mac OS X (je suis tuxophile), mais nmap étant un logiciel libre, j'imagine qu'il existe sous mac...
Bref... : <http://insecure.org/nmap>
Tu me copierias cent fois: I will not ask dumb question before asking google... I will not ask dumb question before asking google... I will not ask dumb question before asking google... I will not ask dumb question before asking google...
avec l'utilitaire de réseau c'est super long, il est lancé depuis plus de 24h et il y est encore ...
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés. Si le scan te rapporte le nom du programme qui écoute derrière, tu pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré comme une tentative d'intrusion, et en tout cas la personne à qui appartient cette machine n'a peut-être pas envie de voir le résultat d'un scan de celle-ci placardé sur le grand ternet mondial. En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te dirais donc de le faire toi-même...
-- Gamelle dans un rond point: tomber dans le domaine public Gamelle sur le parking du supermarché: se vautrer devant tout le monde Hugo (né il y a 1 368 485 651 secondes)
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
bonjour :-)
Bonjour,
avec quels outils on peut scanner les ports efficacement sous mac os x
svp ? :-)
Je ne connais pas Mac OS X (je suis tuxophile), mais nmap étant un
logiciel libre, j'imagine qu'il existe sous mac...
Bref... : <http://insecure.org/nmap>
Tu me copierias cent fois:
I will not ask dumb question before asking google...
I will not ask dumb question before asking google...
I will not ask dumb question before asking google...
I will not ask dumb question before asking google...
avec l'utilitaire de réseau c'est super long, il est lancé depuis
plus de 24h et il y est encore ...
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports
ouverts ou fermés et qui répondent ou non, suivant comment ils sont
configurés.
Si le scan te rapporte le nom du programme qui écoute derrière, tu
pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré
comme une tentative d'intrusion, et en tout cas la personne à qui
appartient cette machine n'a peut-être pas envie de voir le résultat
d'un scan de celle-ci placardé sur le grand ternet mondial.
En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te
dirais donc de le faire toi-même...
--
Gamelle dans un rond point: tomber dans le domaine public
Gamelle sur le parking du supermarché: se vautrer devant tout le monde
Hugo (né il y a 1 368 485 651 secondes)
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
bonjour :-)
Bonjour,
avec quels outils on peut scanner les ports efficacement sous mac os x svp ? :-)
Je ne connais pas Mac OS X (je suis tuxophile), mais nmap étant un logiciel libre, j'imagine qu'il existe sous mac...
Bref... : <http://insecure.org/nmap>
Tu me copierias cent fois: I will not ask dumb question before asking google... I will not ask dumb question before asking google... I will not ask dumb question before asking google... I will not ask dumb question before asking google...
avec l'utilitaire de réseau c'est super long, il est lancé depuis plus de 24h et il y est encore ...
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés. Si le scan te rapporte le nom du programme qui écoute derrière, tu pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré comme une tentative d'intrusion, et en tout cas la personne à qui appartient cette machine n'a peut-être pas envie de voir le résultat d'un scan de celle-ci placardé sur le grand ternet mondial. En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te dirais donc de le faire toi-même...
-- Gamelle dans un rond point: tomber dans le domaine public Gamelle sur le parking du supermarché: se vautrer devant tout le monde Hugo (né il y a 1 368 485 651 secondes)
Nina Popravka
On Sat, 8 Sep 2007 06:46:05 +0200, Hugolino wrote:
Bref... : <http://insecure.org/nmap>
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés. Si le scan te rapporte le nom du programme qui écoute derrière, tu pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
Sans être gourou :
C:Documents and SettingsNina>nmap Nmap 4.22SOC2 ( http://insecure.org ) Usage: nmap [Scan Type(s)] [Options] {target specification} [...] SCAN TECHNIQUES: -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans -sU: UDP Scan -sN/sF/sX: TCP Null, FIN, and Xmas scans --scanflags <flags>: Customize TCP scan flags -sI <zombie host[:probeport]>: Idlescan -sO: IP protocol scan -b <ftp relay host>: FTP bounce scan --traceroute: Trace hop path to each host --reason: Display the reason a port is in a particular state [...]
-- Nina
On Sat, 8 Sep 2007 06:46:05 +0200, Hugolino <hugolino@free.fr> wrote:
Bref... : <http://insecure.org/nmap>
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports
ouverts ou fermés et qui répondent ou non, suivant comment ils sont
configurés.
Si le scan te rapporte le nom du programme qui écoute derrière, tu
pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
Sans être gourou :
C:Documents and SettingsNina>nmap
Nmap 4.22SOC2 ( http://insecure.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
[...]
SCAN TECHNIQUES:
-sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
-sU: UDP Scan
-sN/sF/sX: TCP Null, FIN, and Xmas scans
--scanflags <flags>: Customize TCP scan flags
-sI <zombie host[:probeport]>: Idlescan
-sO: IP protocol scan
-b <ftp relay host>: FTP bounce scan
--traceroute: Trace hop path to each host
--reason: Display the reason a port is in a particular state
[...]
On Sat, 8 Sep 2007 06:46:05 +0200, Hugolino wrote:
Bref... : <http://insecure.org/nmap>
Euh, je ne crois pas qu'il y ait de port UDP ou TCP, il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés. Si le scan te rapporte le nom du programme qui écoute derrière, tu pourras en déduire le type de protocole.
Les gourous du ng me corrigerons si je dis des betises :)
Sans être gourou :
C:Documents and SettingsNina>nmap Nmap 4.22SOC2 ( http://insecure.org ) Usage: nmap [Scan Type(s)] [Options] {target specification} [...] SCAN TECHNIQUES: -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans -sU: UDP Scan -sN/sF/sX: TCP Null, FIN, and Xmas scans --scanflags <flags>: Customize TCP scan flags -sI <zombie host[:probeport]>: Idlescan -sO: IP protocol scan -b <ftp relay host>: FTP bounce scan --traceroute: Trace hop path to each host --reason: Display the reason a port is in a particular state [...]
-- Nina
Pascal Hambourg
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports
dans d'autres protocoles de transport. Chaque protocole de transport
gère ses ports indépendamment des autres protocoles.
il y a des ports
ouverts ou fermés et qui répondent ou non, suivant comment ils sont
configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un
port fermé réponde, mais la réponse ne sera pas la même. Par contre un
port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un
port fermé doit normalement provoquer l'envoi d'un message d'erreur
ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et
donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP
ouvert ne répond pas forcément ; cela dépend du processus qui écoute
derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP
est souvent plus long et moins fiable qu'un scan TCP.
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
Hugolino
Le Sat, 08 Sep 2007 10:59:12 +0200, Pascal Hambourg a écrit:
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
OK, merci pour ce petit cours. Je crois que je vais lire ce ng plus assidument...
-- <rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le firewall que netstat -an fait coredump Hugo (né il y a 1 368 701 810 secondes)
Le Sat, 08 Sep 2007 10:59:12 +0200, Pascal Hambourg a écrit:
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports
dans d'autres protocoles de transport. Chaque protocole de transport
gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant
comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un
port fermé réponde, mais la réponse ne sera pas la même. Par contre un
port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un
port fermé doit normalement provoquer l'envoi d'un message d'erreur
ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et
donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP
ouvert ne répond pas forcément ; cela dépend du processus qui écoute
derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP
est souvent plus long et moins fiable qu'un scan TCP.
OK, merci pour ce petit cours. Je crois que je vais lire ce ng plus
assidument...
--
<rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le
firewall que netstat -an fait coredump
Hugo (né il y a 1 368 701 810 secondes)
Le Sat, 08 Sep 2007 10:59:12 +0200, Pascal Hambourg a écrit:
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
OK, merci pour ce petit cours. Je crois que je vais lire ce ng plus assidument...
-- <rominet> Entendu chez HSC : il y a tellment de ports ouverts sur le firewall que netstat -an fait coredump Hugo (né il y a 1 368 701 810 secondes)
Thomas
In article <fbto92$2uuq$, Pascal Hambourg wrote:
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
merci :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <fbto92$2uuq$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Salut,
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports
dans d'autres protocoles de transport. Chaque protocole de transport
gère ses ports indépendamment des autres protocoles.
il y a des ports
ouverts ou fermés et qui répondent ou non, suivant comment ils sont
configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un
port fermé réponde, mais la réponse ne sera pas la même. Par contre un
port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un
port fermé doit normalement provoquer l'envoi d'un message d'erreur
ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et
donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP
ouvert ne répond pas forcément ; cela dépend du processus qui écoute
derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP
est souvent plus long et moins fiable qu'un scan TCP.
merci :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
est ce que c'est possible de scanner les ports udp aussi ?
Euh, je ne crois pas qu'il y ait de port UDP ou TCP,
Si, il y a bien des ports TCP, des ports UDP, et pourquoi pas des ports dans d'autres protocoles de transport. Chaque protocole de transport gère ses ports indépendamment des autres protocoles.
il y a des ports ouverts ou fermés et qui répondent ou non, suivant comment ils sont configurés.
Pas si simple. En TCP, le protocole impose qu'un port ouvert comme un port fermé réponde, mais la réponse ne sera pas la même. Par contre un port filtré peut ne pas répondre. En UDP, la réception d'un paquet à un port fermé doit normalement provoquer l'envoi d'un message d'erreur ICMP, mais la machine peut limiter le taux d'émission d'erreurs ICMP et donc ne pas répondre à tous les paquets lors d'un scan. Un port UDP ouvert ne répond pas forcément ; cela dépend du processus qui écoute derrière et du protocole de niveau supérieur qu'il utilise. Le scan UDP est souvent plus long et moins fiable qu'un scan TCP.
merci :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
Thomas
In article , Hugolino wrote:
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré comme une tentative d'intrusion, et en tout cas la personne à qui appartient cette machine n'a peut-être pas envie de voir le résultat d'un scan de celle-ci placardé sur le grand ternet mondial.
pas de pb
En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te dirais donc de le faire toi-même...
voilà :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <slrnfe4a8d.8je.hugolino@deborah.rock-n-roll.org>,
Hugolino <hugolino@free.fr> wrote:
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré
comme une tentative d'intrusion, et en tout cas la personne à qui
appartient cette machine n'a peut-être pas envie de voir le résultat
d'un scan de celle-ci placardé sur le grand ternet mondial.
pas de pb
En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te
dirais donc de le faire toi-même...
voilà :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
Le Sat, 08 Sep 2007 00:54:47 +0200, Thomas a écrit:
si qqn veut bien me le faire lui même, c'est pour 81.56.128.208 :-)
Je me demandes dans quelle mesure un nmap ne peut pas être considéré comme une tentative d'intrusion, et en tout cas la personne à qui appartient cette machine n'a peut-être pas envie de voir le résultat d'un scan de celle-ci placardé sur le grand ternet mondial.
pas de pb
En plus cette IP n'est pas celle de ton NNTP-Posting-Host, donc je te dirais donc de le faire toi-même...
voilà :-)
-- j'agis contre l'assistanat, je travaille dans une SCOP !
