Pour exposer ton PC, tu peux définir son adresse comme DMZ dans la configuration de la box. Mais pour scanner une bécane le mieux est AMA de lancer nmap depuis une autre bécane qu’on maîtrise dans le même réseau local. Parce que la fiabilité de ces sites de scan sur internet n’est pas assurée entre ce que filtrent les box, les hébergeurs et les FAI, notamment le port SMTP, les ports Netbios, voire tous les ports inférieurs à 1024 comme Club-Internet à une époque.
Intéressant cette discussion sur ICMP. Les bloquer ou pas semble être un sujet de discussion sans fin entre le responsable d’un réseau et son collègue de la sécurité:
daemon.be/maarten/icmpfilter.html
Si tout se passe bien avec ICMP bloqué, que le réseau fonctionne (apparemment) bien, ce qui est mon cas, faut-il quand même ouvrir un serveur à ICMP?
Je viens de faire un traceroute vers une machine sans rien d’ouvert, depuis une machine hors LAN et les seuls paquets que je vois arriver sur la cible sont des paquets UDP. Y-a-t’il un intérêt à faire un traceroute avec d’autres protocoles (options -I pour ICMP et -T pour TCP)?
[quote=“ripat”]Intéressant cette discussion sur ICMP. Les bloquer ou pas semble être un sujet de discussion sans fin entre le responsable d’un réseau et son collègue de la sécurité:
daemon.be/maarten/icmpfilter.html[/quote]
Tout est question de compromis entre ce qu’il est nécessaire ou simplement utile de laisser passer et ce qui est potentiellement dangereux, l’intersection des deux ensembles n’étant pas vide.
La menace de fuites par tunnelling dans ICMP qui est évoquée me fait sourire, il y a bien d’autres protocoles exploitables, par exemple DNS.
Je suis surpris que l’auteur recommande de bloquer le type 11/code 1 (fragment reassembly time exceeded) au motif qu’il facilite l’identification de l’OS (fingerprinting). Ceci dit ce message n’est pas absolument indispensable, un fragment non reçu c’est comme un paquet perdu, pour lequel il n’y a pas forcément de message d’erreur.
En parlant de fragmentation, j’ai quelques remarques.
L’auteur, et il n’est pas le seul, recommande de bloquer les messages ICMP fragmentés car soi-disant ils ne sont pas courants sauf en cas de malveillance. Moi j’utilise régulièrement des messages ICMP fragmentés, par exemple des pings pour étudier des problèmes de MTU assymétriques : si j’envoie un ping de taille maximum pour moi alors que le destinataire a un MTU inférieur, il devra fragmenter la réponse au ping. Si les ICMP fragmentés sont bloqués en chemin, je ne recevrai pas la réponse.
La règle iptables avec l’option --fragment ne bloque pas tous les fragments mais seulement le deuxième et suivants d’un datagramme. Le premier fragment, celui qui a l’offset 0 et contient le début du datagramme, avec normalement l’en-tête du protocole transporté (et donc les ports en TCP ou UDP, le type/code en ICMP…), n’est pas concerné par cette option. Or laisser passer le premier fragment, cela signifie que la pile IP du destinataire va créer un tampon pour reconstituer le datagramme complet et démarrer une temporisation pour la réception des autres fragments, ce qui mobilise des ressources pour rien si les autres fragments sont bloqués. Si on voulait bloquer le premier fragment, il faudrait un test qui se base sur la présence du drapeau “more fragments” de l’en-tête IP, mais à ma connaissance il n’y a pas de test prévu pour cela dans iptables. On devrait néanmoins pouvoir le réaliser avec la correspondance ‘u32’ (incluse en standard à partir du noyau 2.6.23) qui permet d’extraire des motifs binaires d’un paquet.
Mais tous ces efforts risquent d’être vains pour deux raisons. La première, c’est que les fragments à destination locale sont réassemblés avant d’entrer dans les chaînes INPUT des tables ‘mangle’ et ‘filter’. Par conséquent l’option -f ou --fragment est inutile dans les règles de ces chaînes. Si on veut filtrer les fragments reçus il faut le faire dans la chaîne PREROUTING de la table ‘raw’ ou ‘mangle’.
La seconde concerne tout ceux qui utilisent le suivi de connexion de netfilter, soit pour faire du NAT (MASQUERADE, SNAT, DNAT…) soit pour faire du filtrage à état (-m state ESTABLISHED…), c’est-à-dire beaucoup de monde. Le suivi de connexion de netfilter a besoin de travailler sur les datagrammes complets et donc réassemble les fragments avant les chaînes PREROUTING des tables ‘mangle’ et ‘nat’. Le seul endroit où on puisse les filtrer est alors la chaîne PREROUTING de la table ‘raw’, traversée avant le suivi de connexion car prévue à l’origine pour marquer les paquets devant être ignorés par le suivi de connexion.
Il est plus prudent d’autoriser les types de messages d’erreur indispensables qui ont déjà été mentionnés dans ce fil.
Pour un traceroute UDP, ce sont les réponses des routeurs intermédiaires qui sont des messages ICMP de type “TTL exceeded in transit”, et la réponse du destinataire de type “port unreachable” si le port UDP ciblé est fermé (mais pas bloqué). Il ne faut pas bloquer ces messages ICMP si on veut que le traceroute marche.
Les traceroutes avec d’autres protocole ont un intérêt quand les paquets UDP sont bloqués par un firewall. Si en revanche le ping passe, le traceroute ICMP passera. Le traceroute TCP permet de passer à travers un firewall qui ne laisse passer qu’un seul port TCP particulier, et aussi de vérifier l’accessibilité du service hébergé sur ce port, ce que ne font pas les autres. Par exemple un serveur web peut ne pas répondre au ping, au traceroute UDP et ICMP mais il doit répondre au traceroute TCP sur le port 80 puisque ce port est ouvert.
Un peu plus loin au sujet de l’utilisation d’ICMP à des fins de tests:
[quote] if you use ICMP echo for timing or testing reasons, you will want to be able to vary the length of the packets and possibly the patterns of the data in them (some transmission mechanisms are quite sensitive to bit patterns, and speeds may vary depending on how compressible the data is, for instance). You are therefore allowed to put arbitrary data into the body of ICMP echo packets, and that data is normally ignored; it’s not filtered, logged, or examined by anybody. For someone who wants to smuggle data through a firewall that allows ICMP echo, these bodies are a very tempting place to put it. They may even be able to smuggle data into a site that allows only outbound echo requests by sending echo responses even when they haven’t seen a request. This will be useful only if the machine that the responses are being sent to is configured to receive them; it won’t help anyone break into a site, but it’s a way for people to maintain connections to compromised sites.
docstore.mik.ua/orelly/networkin … #ch04-4684[/quote]
Par contre, je viens de lire un passage qui me donne une réponse à ma question plus haut: il conviendrait effectivement de ne pas tout bloquer car ça pourrait empêcher le ‘MTU discovery’ ce qui pourrait poser problème dans l’optimisation de la vitesse d’une connexion ayant besoin d’envoyer un gros volume de données.
[quote]…However, path MTU discovery will fail catastrophically if the error messages (which are ICMP messages, discussed later in this chapter) are not correctly returned (for instance, if your firewall drops them)
docstore.mik.ua/orelly/networkin … #ch04-4492[/quote]
Les recommandations des auteurs pour ICMP:
docstore.mik.ua/orelly/networkin … ch22-15772
Ils recommandent entre-autre de ne pas autoriser les ICMP de type 3 pour cette raison:
Par contre je n’ai pas trouvé quel type de message permettait le ‘MTU discovery’? Ce n’est pas justement un sous-type du groupe 3?
PS: Grâce à cette relecture, j’ai enfin compris ce qu’était le “Source quench”: "Ralentis, tu parles trop vite!"
Source quench (somebody telling destination “slow down; you’re talking too fast”). 
Désolé d’avoir laissé la discussion en suspens et de répondre si tardivement.
[quote=“ripat”]Les recommandations des auteurs pour ICMP:
docstore.mik.ua/orelly/networkin … ch22-15772
Ils recommandent entre-autre de ne pas autoriser les ICMP de type 3 pour cette raison:
Cette recommandation concerne les messages ICMP émis en sortie, pas ceux reçus en entrée. Si on les bloque en sortie, on gêne la source du paquet ayant provoqué le message d’erreur en le privant d’information sur l’état du réseau. Par contre si on les bloque en entrée, on a toutes les chances de se gêner soi-même puisqu’on se prive soi-même d’informations sur l’état du réseau.
Oui, c’est le type 3 code 4 “Fragmentation Needed and Don’t Fragment was Set”, “fragmentation-needed” pour iptables. Ce message ne peut être émis que par un routeur, pas par un “hôte” (station ou serveur). Un hôte ne doit pas le bloquer en entrée. Il peut en revanche le bloquer en sortie, de toute façon il n’est pas censé en envoyer. Un routeur ne devrait pas le bloquer ni en entrée, ni en sortie, ni en forward.