Faq Securite scan de ports

JB wrote:

Ce serveur : | <http://scan.sygatetech.com>
m'indique que tous les ports UDP sont "fermés"
une ouverture ne peut se faire qu'à partir de ma machine passerelle?
ICMP, le teste ne peut se faire puisque pas de réponse au ping
A+
JB

ICMP != ping,

ping C ICMP

--
SL

SL wrote:

JB wrote:

Ce serveur : | <http://scan.sygatetech.com>
m'indique que tous les ports UDP sont "fermés"
une ouverture ne peut se faire qu'à partir de ma machine passerelle?
ICMP, le teste ne peut se faire puisque pas de réponse au ping
A+
JB

ICMP != ping,

ping C ICMP

le message exact:

ICMP scan:

* Uses various methods to determine if your firewall blocks ICMP packets (PING).

C'est vrai ceci est implémenté
A+
JB

Ce serveur : | <http://scan.sygatetech.com>
m'indique que tous les ports UDP sont "fermés"
une ouverture ne peut se faire qu'à partir de ma machine passerelle?
ICMP, le teste ne peut se faire puisque pas de réponse au ping
A+
JB
Il me semble que le scan UDP est justement basé sur les réponses ICMP

(je ne sais plus quel type) de la machine scannée.
Une machine configurée pour ne pas envoyer de telles réponses ne
signifierait donc pas forcément qu'aucun port UDP n'est accessible ?

moncul wrote:

Il me semble que le scan UDP est justement basé sur les réponses ICMP
(je ne sais plus quel type) de la machine scannée.

"Port unreachable", il y a un peu plus de détails là (en anglais), avec les RFC
de référence:
http://www.snort.org/docs/faq/1Q05/node61.html

Une machine configurée pour ne pas envoyer de telles réponses ne
signifierait donc pas forcément qu'aucun port UDP n'est accessible ?

D'autant que cette réponse ICMP n'est pas systématique comme l'est un RST sur un
port TCP fermé. La machine visée ne répond pas à *toutes* les tentatives,
seulement à une partie (1 sur 3 est la valeur courante, me semble-t-il).
Si je ne me trompe pas, cela signifie que si l'on envoie un seul paquet UDP sur
un port donné, on a 2 chances sur 3 de ne jamais recevoir de réponse, même si la
machine est configuré pour en renvoyer.

Laurent

On Wed, 04 May 2005 17:12:36 +0000, Laurent Blume wrote:

D'autant que cette réponse ICMP n'est pas systématique comme l'est un
RST sur un port TCP fermé. La machine visée ne répond pas à *toutes*
les tentatives, seulement à une partie (1 sur 3 est la valeur courante,
me semble-t-il).

Pas d'accord. Dans un contexte "ouvert" (ie. pas de fw ou autre astuce),
tout paquet UDP envoyé à un port fermé est censé générer un ICMP
"Port unreachable" en retour. Bien que certaines piles IP (Solaris, Linux)
implémentent une limitation sur le nombre de paquets ICMP émis dans un
certain espace de temps (comme préconisé dans le paragraphe "4.3.2.8" de
la RFC 1812), je ne vois pas d'où sort ce ratio de 1/3.


Nicob

On Fri, 06 May 2005 09:56:57 +0000, Nicob wrote:

Dans un contexte "ouvert" (ie. pas de fw ou autre astuce), tout paquet
UDP envoyé à un port fermé est censé générer un ICMP "Port
unreachable" en retour.

Et dans un contexte "fermé", la meilleure solution pour faire du scan de
ports UDP est à mon avis de monter au niveau applicatif afin de tenter de
faire réagir les services réseau en écoute.

Nmap se contente (avec -sU) d'envoyer des paquets avec 0 octets de
payload. L'ajout d'un "-sV" permet d'introduire un scan applicatif fort
utile pour la recherche de ports UDP ouverts (cf. nmap-service-probes)

Unicorscan fait quant à lui nativement le scan UDP au niveau applicatif,
et annonce 56 types de payloads UDP différentes.


Nicob

Nicob wrote:

Pas d'accord. Dans un contexte "ouvert" (ie. pas de fw ou autre astuce),
tout paquet UDP envoyé à un port fermé est censé générer un ICMP
"Port unreachable" en retour. Bien que certaines piles IP (Solaris, Linux)
implémentent une limitation sur le nombre de paquets ICMP émis dans un
certain espace de temps (comme préconisé dans le paragraphe "4.3.2.8" de
la RFC 1812), je ne vois pas d'où sort ce ratio de 1/3.

De ma mauvaise mémoire, sûrement, je n'étais pas sûr, et ne me rappelais
absolument pas de la RFC.

Ceci dit, vu le paragraphe en question, il est possible que je sois tombé un
jour sur la description d'une implémentation qui faisait du 1/3 sur du Source
quench, et que ce soit resté (un peu mélangé) dans mes souvenirs:

(1) Count-based - for example, send an ICMP error message for
every N dropped packets overall or per given source host.
This mechanism might be appropriate for ICMP Source Quench,
if used, but probably not for other types of ICMP messages.

Ceci dit, sur le fond, il n'en reste pas moins que dans la pratique, un paquet
UDP arrivant sur un port fermé ne génère pas *systématiquement* un ICMP port
unreachable. D'après ce que je voie entre deux hôtes Solaris, Nmap envoie
plusieurs paquets UDP par port, en changeant le numéro de port source. Je ne
sais pas si c'est conforme ou pas à la RFC, que je n'ai parcouru que très vite.
Est-ce que ça permet d'éviter d'inonder une machine innocente en bombardant un
hôte relais avec des paquets à l'origine usurpée?

Laurent

On Fri, 06 May 2005 16:25:48 +0000, Laurent Blume wrote:

Est-ce que ça permet d'éviter d'inonder une machine innocente en
bombardant un hôte relais avec des paquets à l'origine usurpée?

Sans amplification, c'est pas très intéressant. Quitte à faire ça, je
partirais sur un SYN Flood ...


Nicob

Salut,

(1) Count-based - for example, send an ICMP error message for
every N dropped packets overall or per given source host.
This mechanism might be appropriate for ICMP Source Quench,
if used, but probably not for other types of ICMP messages.

Est-ce que ça permet d'éviter d'inonder une machine innocente en bombardant un
hôte relais avec des paquets à l'origine usurpée?

La RFC 1812 explique juste au-dessus que c'est dans le but d'économiser
les ressources de la machine et du réseau :

Two problems for a router sending ICMP error message are:
(1) The consumption of bandwidth on the reverse path, and
(2) The use of router resources (e.g., memory, CPU time)

J'y vois au moins un intérêt évident en cas de liaison à débits
asymétriques comme l'ADSL.

Par contre je n'ai pas trouvé l'équivalent dans la RFC 1122 qui concerne
les hôtes non routeurs.