web-dev-qa-db-fra.com

Ports filtrés - Qu'est-ce qui les filtre exactement?

Selon la définition NMAP, les ports non filtrés sont ceux qui ne peuvent pas être déterminés comme étant ouverts ou fermés car le filtrage de paquets empêche ses sondes d'atteindre le port. (ISBN 9780979958717 pag. 77)

  • Cela étant dit, mon hypothèse est-elle correcte que chaque sonde qui parvient à atteindre le port sera toujours correctement répondue par un SYN/ACK ou un RST?
  • La seule chose qui pourrait m'empêcher d'accéder au port ou d'obtenir une réponse serait un dispositif de sécurité (par exemple, un pare-feu) - est-ce exact?
  • L'application elle-même ne peut-elle pas simplement ignorer mes sondes?
ipnetwork-scannersnmap
11
user69377

Généralement, il existe plusieurs appareils entre vous et votre cible. En cours de route, les pare-feu, routeurs, commutateurs et autres périphériques réseau peuvent empêcher vos paquets d'atteindre réellement votre cible. Les pare-feu basés sur l'hôte ou les contrôles d'accès aux applications peuvent également provoquer une réponse filtrée.

Parfois, vous obtenez une réponse du périphérique de filtrage dans la réponse d'un message d'erreur ICMP, mais dans la plupart des cas, quelque part sur la route, les paquets sont simplement abandonnés.

Vos hypothèses:

  • Non. Iptables peut être configuré pour ne pas répondre du tout sauf si vous êtes sur une liste approuvée. Ou iptables peut être configuré avec une liste d'hôtes/réseaux pour ne pas répondre du tout.
  • Cela dépend de la façon dont vous définissez le dispositif de sécurité. Un meilleur terme serait dispositif de contrôle d'accès car il pourrait s'agir de quelque chose comme des ACL sur un routeur.
  • Selon l'application et sa pile de mise en réseau, c'est possible. Une application avec une pile de réseau terrestre d'utilisateurs peut choisir ce qu'il faut faire des demandes au lieu du système d'exploitation.
8
dmay

Dans la plupart des systèmes d'exploitation, la gestion de la liaison à trois voies TCP est la responsabilité du code réseau du système d'exploitation. Les applications ne peuvent déclarer leur intérêt à recevoir des connexions sur un certain port que par le biais de l'écoute () appel système. Le système d'exploitation répondra à un SYN avec un SYN/ACK s'il y a une application à l'écoute sur le port, et avec un RST sinon. Aucune application n'a son mot à dire.

Il s'agit du comportement par défaut. Il peut être modifié par de nombreuses choses, y compris, mais sans s'y limiter, les mécanismes de filtrage des paquets sur l'hôte. De plus, l'implémentation spécialisée de TCP/IP peut se comporter différemment à dessein.

Lorsque NMAP ne reçoit ni SYN/ACK ni RST en réponse à un paquet SYN, il signale ce port comme "filtré". Il n'a aucun moyen de déterminer la raison pour laquelle il n'a pas reçu de réponse. Inversement, si un pare-feu intermédiaire bloque le port en répondant avec RST, NMAP signalera le port comme fermé, même si le paquet de sonde n'a jamais atteint sa destination.

En somme, votre devis est au moins inexact. NMAP signale également les ports comme filtrés s'ils ne peuvent pas être déterminés comme ouverts ou fermés pour des raisons autres autres que le filtrage de paquets. Le filtrage de paquets n'est que la cause la plus courante et est donc devenu l'éponyme de ce résultat. De plus, NMAP peut même signaler un port comme fermé lorsqu'il ne peut pas le déterminer comme ouvert ou fermé en raison d'un filtre de paquets intermédiaire.

9
Tilman Schmidt

En essayant d'entrer dans la forme la plus simple du réseau cible :

 Internet --- pare-feu --- cible

vous traverserez au moins 3 niveaux de filtrage:

  1. pare-feu
  2. au niveau du système d'exploitation de la cible
  3. au niveau application de la cible

À chacun de ces niveaux, un 1er paquet IP (et tout autre paquet de protocole en tant que ESP ou paquet AH) peut recevoir 4 types de traitement:

  1. le paquet est simplement abandonné (pas de forme de réponse)
  2. le paquet est abandonné et un ICMP type 3, code 9 ou 10 est retourné,
  3. recevoir un TCP paquet RST
  4. recevoir un TCP paquet ACK

De vrais réseaux sont constitués de cette brique de base.

3
dan

Il y a plusieurs questions ici, laissez-moi essayer de les reformuler, afin qu'une réponse appropriée puisse être donnée.

Question 1. Les systèmes répondent-ils avec SYN/ACK ou RST si le trafic atteint un hôte?

Réponse courte - pas nécessairement, vous pouvez obtenir une destination ICMP inaccessible (port inaccessible), qui est considérée comme une réponse acceptable lorsqu'il n'y a pas de processus d'écoute sur ce port ( RFC 1122 , page 40 et RFC 792 , page 5). Vous pouvez également ne recevoir aucune réponse - malheureusement, tout le monde ne se conforme pas aux spécifications RFC. Malheureusement, j'ai vu des implémentations qui répondent à SYN avec un FIN! Oui, ça peut être si mauvais.

Question 2. Est-ce que chaque sonde qui parviendra à atteindre le port recevra une réponse appropriée?

Réponse courte - pas nécessairement, TCP d'un système d'exploitation à l'autre varient, par exemple, j'ai vu des systèmes embarqués avec des ressources limitées qui ont échangé le processus d'écoute et au moment où le processus a été restauré en mémoire, la fenêtre d'opportunité pour une réponse s'est fermée. C'est une exception plutôt que la règle, mais vous devez garder à l'esprit que tout le monde ne respecterait pas la norme - certains peuvent avoir des mécanismes de protection contre les inondations SYN intégrés qui peut voir trop de segments SYN du même hôte comme une tentative de DoS.

Question 3. Une application peut-elle ignorer les sondes?

En règle générale, ce n'est pas la responsabilité de l'application de le faire, c'est la pile du système d'exploitation qui s'occupe de ces choses. Cela ne veut pas dire que vous ne pouvez pas implémenter votre propre gestionnaire de protocole, mais c'est rarement le cas. Mais je dirais que peu d'applications ont leur mot à dire dans la partie TCP poignée de main de leurs communications).

J'espère que ces réponses vous seront utiles :-)

0
Milen