Propos et Commentaires du Climenole

COMMENT CRÉER DES RÈGLES POUR VOS APPLICATIONS – première partie

1- Les programmes internets et l’assignation des ports

L’attribution des ports pour les services et applications est du ressort de l’I.A.N.A. Les 65535 ports logiques sont divisées entre les ports “bien connus” de 0 à 1023, “enregistrés” de 1024 à 49151 et “dynamiques” de 49152 à 65535. Certains d’entre eux sont assignés, d’autres non, sans compter les ports “officieusement” assignées et l’utilisation anarchique de n’importe quel ports assignées ou non par certaines applications internets ce qui n’est pas sans causer des conflits, des ports étant utilisés par des application différentes.

Références:

I.A.N.A.
Assignation des ports, officielle ou non

Pour la plupart des applications courantes les ports utilisés correspondent bien à ceux assignés par l’I.A.N.A. mais un bon nombre parmis les applications tel que la VoIP, les messageries instantanées et les applications “multimédia” ont des normes plutôt “flottantes” ou ne tiennent aucun compte de l’assignation des ports.

2- Les programmes, les connexions et la documentation

La plupart des applications internets se connectent aux serveurs en utilisant le premier port local disponible dans la gamme 1024 à 5000. La connection d’un navigateur à un serveur web en est un bon exemple. Lorsque l’URL est entré dans le champ d’adresse du navigateur, le système d’exploitation vérifie la présence ou non de l’URL dans le fichier HOSTS. Si l’URL n’y est pas une requête Domain Name Service est lancée en UDP vers le port 53 du serveur DNS, l’URL est traduite en adresse IP et la connexion est initiée par le navigateur par un paquet TCP sans donnée et avec le flag SYN activé. Le premier port disponible dans la gamme 1024 à 5000 est utilisé et la connection se déroule entre ce port et le port 80 du serveur web tout au long de cette connexion. Rien de plus simple alors de créer une règle pour une telle application.

Si toutes les applications était ainsi faites, l’élaboration de règles serait presqu’un jeu d’enfant: il suffirait d’indiquer au pare-feu le ou les ports distants officiellement assignées pour l’application. Mais ce n’est pas le cas: les ports locaux utilisés pour initier la connection peuvent être différents de la gamme 1024-5000, utiliser plus d’un port local dans le déroulement de la connexion ou encore, obliger l’utilisation d’une gamme de ports distants étendue et aléatoires. Le cas le plus ancien est le protocole FTP qui a l’honneur de figurer en tête de la liste des protocoles à “contenu sale”.

Enfin, pour épicer le tout, un très grand nombre d’application n’ont pas de documentation ou une documentation déficiente, incomplète ou incorrecte. Aussi incroyable que cela puisse paraître il semble de toute évidence que les derniers à connaître le comportement exact d’un programme lors des connections internets en soient trop souvent les auteurs.

3- L’exemple des navigateurs et l’utilisation des ports

Rien de plus simple semble-t-il que les règles pour les navigateurs: la gamme de ports locaux de 1024 à 5000 est utilisée pour initier les connections vers les serveurs web en Http vers le port 80 ou en Https vers le port 443. On note au passage l’existence du port 8080, un port Http alternatif utilisé par quelques sites. Cependant plusieurs navigateurs ajoutent aux fonctions de navigation d’autres fonctions: courrier, messagerie, Nntp, etc.

Cela suppose donc que les règles tiennent compte de toutes ces fonctions ET que ces règles soient activée chaque fois que le programme est lancé, que ces fonctions soient utilisées ou non. C’est le résultat de la tendance à transformer les outils simples en “canif suisse”, “couteau de survie Rambo”, “suite logicielle” ou, pour parler vulgairement, d’usine à gaz [flatuliciel © climenole]. L’empiètement d’un programme sur les fonctions des autres et le je-m’en-foutisme dans l’utilisation des ports est AMHA le résultat de l’exemple déplorable donné par Microsoft ™ tant avec l’Omniprésent et l’Indécrottable InterNUT Expl’horreur [© climenole] intégré à Windows ™ à la façon d’une tumeur inopérable que par le laxisme incroyable de la même bande présentant une demi-barrière de broches à poules comme étant un pare-feu. Tel maître, tels valets.

4- Règles pour les applications les plus courantes

Navigateurs (HTTP / HTTPS)

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Égale ou 80 HTTP, 443 HTTPS
• Application(s): exécutables du navigateur
• En supplément:
• Destination Port(s): Alt-HTTP 8080
• Autres: FTP via l’HTTP et d’autres fonctions optionnelles.

Courrielleurs (SMTP/POP3 ou SMTP/IMAP4 ou SSL/TLS)

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): Égale ou 25 SMTP, 110 POP3
• Destination Ports(s): Égale ou 25 SMTP, 143 IMAP4
• Destination Ports(s): Égale ou 995 POP3S, 587 TLS *
• En supplément:
• Destination Ports(s) 80 HTTP affichage HTML et les mises à jour.
• Destination Ports(s) 11371 HKP accès aux serveurs de clés publiques OpenPGP
• * le port SMTP TLS varie selon le courrielleur utilisé. Voir l’aide de GMail…

Clients IRC

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Entre 6667-6669
• En supplément:
• Source Port: IDENT 113 en tant que serveur!

Clients NNTP

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Égale 119
• En supplément: parfois aussi utilisé comme client de courrier

Clients Jabber

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000 (connexions)
• Source Port: 5222 (communications)
• Destination Adresse(s) IP: Toutes
• Destination Port(s): 5222 *(ou 5223 pour l’accès à Gtalk avec un autre client)
• Destination Port: 8010 (échanges de fichiers)
• Commentaire: dans le cas de Gtalk HTTP + HTTPS pour le “login”

Notez que la plupart des applications locales ont parfois besoin d’une connection en HTTP pour accéder au site web de l’éditeur du programme, pour une aide en ligne ou pour les mises à jour du produit. Dans ce dernier cas les mises à jour sont lancées depuis le programme lui-même ou par un programme spécifique. D’autres applications ne posent pas non plus de problème car les accès sont en général documentés correctement (VNC et ses variantes par exemple). À part quelques exceptions faciles à gérer les programmes internets mentionnés sont plutôt faciles en comparaison de ceux qui vont suivre.

5- Les protocoles à “contenu sale”, à “n’importe quoi” et à “géométrie variables”

À part le cas du FTP et du serveur IDENT, il n’est pas question de donner une énumération à dormir debout de toutes les règles possibles pour les applications multimédias, les messageries instantanées, les clients VoIP, les Jeux, P2P, etc.

Une méthode pour créer des règles sur mesure est plus pratique puisqu’elle est universelle: valable pour toutes les applications peu importe qu’elle soit ou non documentée.

Le protocole applicatif FTP et ses modes ou le “contenu sale”

Dans le cas du mode actif le client se connecte au port 21 du serveur FTP et les données sont transférées sur l’un des ports locaux prédéterminés par le client à partir du port 20 du serveur FTP. Ce mode implique qu’une nouvelle connexion soit initiée par le serveur FTP vers le client pour la transmission des données.

Dans ce cas il faut 2 règles pour l’utilisation du FTP en mode actif:

une règle pour la connexion du client vers le port 21 du serveur FTP et une règle pour la nouvelle connexion initiée depuis le port 20 du serveur FTP vers le client sur l’un des ports d’une gamme prédéterminée. Cela constitue donc une connexion de type serveur puisque le client doit accepter une connexion entrante en provenance du serveur FTP vers son propre système (Paquet TCP + flag SYN).

Il y a donc dans le protocole applicatif FTP des échanges de ports et d’adresses IP ne devant normalement se dérouler qu’au niveau des protocoles de transport (TCP/UDP).

De plus l’utilisation du FTP en mode actif initie une deuxième connexion de type serveur sur le client lui-même comme nous venons de le voir.

Enfin dans les deux modes les ports utilisés pour les transferts sont imprévisibles et obligent la mise à la disposition des applications utilisant le FTP une large de ports. On peut parler ici de “protocoles à larges culottes”…

Dans le cas du mode passif le client se connecte au port 21 du serveur FTP et les données sont transférées au client depuis n’importe quel port du serveur FTP vers l’un des ports du client au cours de la même connexion (initiée par le client). Ce dernier mode est plus sécuritaire puisqu’il se déroule à l’intérieur d’une connexion unique initiée par le client.

Clients FTP (et fonctions FTP du navigateur) en mode passif

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port: 21 FTP-control [première règle]
• Destination Port(s): 49153 à 65535 (parfois 1024 à 65535) [deuxième règle]
• Références: Protocoles réseau à contenu sale
• Commentaires:
• le FTP utilisé via un client FTP tel que Filezilla ne pose pas de problèmes particuliers à part ceux mentionnés dans la référence donnée pour ce protocole. Cependant, en tant que fonction du navigateur cela oblige à chaque fois que celui-ci est lancé à laisser la possibilité d’ouvir l’accès sur une gamme de ports distants étendue tout à fait inutile pour les besoins normaux de navigation.
• De plus cela semble causer quelques ennuis à Look’n'Stop si une autre application utilisant elle aussi une gamme de ports étendue est lancée en même temps. Le pare-feu tend à mélanger les pinceaux au moins au niveau de la journalisation: des accès de MSN Messenger ou d’ITunes pour l’écoute en stream étant journalisés comme des accès FTP.
• Ceci est un exemple d’une limitation de Look’n'Stop: pare-feu à état mais pas pare-feu d’applications proprement dit; il n’y a pas de vérification ni de différence faites entre des paquets FTP ou HTTP par exemple. Un un mot, L’n'S reconnaît bien les paquets du niveau Transport (TCP, UDP, ICMP, etc.) mais ne distingue pas les échanges au niveau applicatif (HTTP, FTP, SIP, etc.). Ces différences sont indirectement (et imparfaitement) contrôlées avec les règles limitant l’accès à des ports distants correspondants au protocoles du niveau 5 des couches TCP-IP. Dans le cas de protocoles “à larges culottes” un méli-mélo semble s’installer au niveau de la détection des sockets…
• Les limitations, les “bugs” et les améliorations souhaitables de Look’n'Stop sortent du cadre de cet article et seront examinés dans de prochains articles.

Client FTP en mode actif

• Serveur: placer obligatoirement entre la règle { G.07} et la règle { Q.999}
• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000 (ou une autre gamme déterminée par le client FTP)
• Destination Adresse(s) IP: Toutes (ou adresses IP des serveurs FTP)
• Destination Port: 20
• Commentaire: ambigüité de source et destination. Dans le cas d’un échange de paquets en entrée et sortie la source et la destination varient. Le terme plus exact serait local [L] plutôt que “source” et distant [D] plutôt que “destination”. C’est d’ailleurs ainsi que les indications doivent être comprises. Dans le cas de l’édition des règles de L’n'S, “source” désigne les champs d’adresses et de ports à gauche, tandis que “destination” désigne les champs à droite.
• 
  

Le protocole IDENT ou le “n’importe quoi”

• Serveur: placer obligatoirement entre la règle { G.07} et la règle { Q.999}
• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 113
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): tous
• Application(s): option du client IRC ou WinIdent
• Références: Ident

Le protocole IDENT serait, paraît-il, important pour les serveurs IRC afin identifier l’accès aux serveurs IRC depuis un système multi-utilisateur afin d’identifier et d’éventuellement bannir cet utilisateur en cas d’abus plutôt que de bannir le système multi-utilisateur à partir duquel il s’est connecté. En cas d’absence de réponse à la requête IDENT le nom de l’utilisateur connecté est alors préfixé avec un tilde [ ~ ] indicant qu’il n’y a pas de nom d’utilisateur obtenu par l’IDENT et que celui-ci pourrait être un “fake”…

Il peut même arriver qu’un serveur IRC bloque l’accès à toute tentative de connection de donnant pas de réponse à la requête IDENT. Une mini-polémique a d’alleurs opposée MM. Erik Fair et Russell Nelson au sujet de ce protocole.Le premier soutenant que ce protocole est sans pertinence et possiblement dangereux, l’autre retournant l’argument cul par dessus tête en soutenant que ce protocole serait des plus utile aux administrateurs de système pour identifier les utilisateurs abusifs (de serveurs IRC…).

Erik Fair: identd (identification protocol) is pointless and potentially dangerous
Russell Nelson: ident is not of use to servers

Pour vous faire une idée vous même je vous invite à consulter le RFC 1413 et en particulier cet extrait (c’est moi qui souligne…):

RFC 1413

«
6- Security Considerations

The information returned by this protocol is at most as trustworthy as the host providing it OR the organization operating the host. For example, a PC in an open lab has few if any controls on it to prevent a user from having this protocol return any identifier the user wants. Likewise, if the host has been compromised the information returned may be completely erroneous and misleading.

The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing information with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information.

The use of the information returned by this protocol for other than auditing is strongly discouraged. Specifically, using Identification Protocol information to make access control decisions – either as the primary method (i.e., no other checks) or as an adjunct to other methods may result in a weakening of normal host security.

An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identification server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Identification. If you wouldn’t run a “finger” server due to privacy considerations you may not want to run this protocol.

»

Pour ma part je soutiens que ce protocole est insignifiant, sans pertinence et utilisé par certains serveurs IRC encroûtés à la façon d’une mauvaise habitude. Il n’aide personne, ni les administrateurs de ces serveurs, ni les utilisateurs, ni les administrateurs de systèmes multi-utilisateurs: personne (même pas les Script Kiddies!). Plus amusant encore il même très facile de donner à la requête IDENT une réponse fantaisiste et gobée telle quelle par les serveurs IRC. Il suffit par exemple d’utiliser le programme WinIdent Server plutôt que l’option de réponse IDENT du client IRC.

Voici une capture d’écran de la connexion d’une machine sous Windows XP se présentant chez Dalnet en tant que BSD Unix à l’aide de WinIdent:

En somme un truc totalement inutile qui nécessite l’installation d’un serveur dont la valeur est douteuse sauf évidemment pour faire une blague ou un clin d’oeil aux serveurs IRC ou autrement de ne pas l’utiliser.
Vous pouvez trouver le programme WinIdent server sur le site de l’auteur (inaccessible?): http://www.rndware.info ou via les réseaux P2P en format zip.

Checksum:

sha1:QKHRVMK6MIEKPVJZ7TZMUJQH3G3FXPY2 md5:4b1e263c071db6ecc50e49bc7f2232ac

Les autres “n’importe quoi” ou protocles fantaisistes

Dans le cas des Messageries et de la VoIP, les fonctions de connexion utilisent le HTTP et le HTTPS mais toutes les autres fonctionnalités: présence, communications vocales et vidéo, échanges de fichiers et autres utilisent un protocole propriétaire, des ports locaux et distants variants selon le service de messagerie utilisée et obligent la plupart du temps à autoriser une gamme très large de ports. Les règles doivent en conséquence être adaptées chaque fois pour accomoder le protocole propriétaire de tel ou tel service de messagerie. Ce sont aussi des “protocoles à larges culottes” nécessaires pour y installer confortablement leur gros derrières flasques.

On note cependant que Jabber permet l’utilisation de d’autres protocoles via les “transports” ce qui permet évidemment de simplifier les règles du pare-feu. Cependant les transports faisant office de passerelles vers d’autres services de messageries sont dépendants de protocles fermés et ne permettent pas en général d’accéder à toutes les fonctions disponibles en utilisant le client de messagerie dédié à ce protocole.

Il en va de même des applications multimédia: les fonctions de “stream” pour l’écoute des radios en lignes par exemple utilisent une multitude de ports distants: aucune norme n’étant prévue pour ces applications. Pour les jeux en lignes: chacun établissant ses propres normes il n’est pas possible d’avoir une règle générale permettant de tous les utiliser.

Enfin les applications de serveurs et de P2P sont relativement bien documentées mais dans le cas des applications P2P l’implantation de règles correctes est plus ardue puisqu’il s’agit à la fois d’application clientes ET d’application serveur.

Le protocole BitTorrent ou à “géométrie variable”

Dans le cas particulier de BitTorrent le port d’accès de la partie serveur est “officiellement” le port TCP 6881. Cependant il est recommandé de ne pas l’utiliser à cause du filtrage de ce port par de nombreux serveurs. Il est suggéré d’utiliser un des ports non assignés par l’I.A.N.A,. tel que, par exemple, 46881. On voit tout de suite le problème: chaque client BT permet le choix de n’importe quel port de serveur. Ce n’est pas tout: le protocole BitTorrent utilise plusieurs port différents pour l’annonce des torrents: les ports 6969 en HTTP ou 7000 en HTTPS sont utilisés mais ce n’est pas toujours le cas et l’annonce peut être faite sur n’importe quel autre. Enfin certains clients BT tel qu’Azureus utilisent aussi le Distributed Hash Table en UDP.

Tout cela ne pose pas vraiment de problèmes pour établir des règles mais oblige encore une fois à permettre l’utilisation d’une gamme importante de ports locaux et distants puisqu’il est impossible de prévoir lequels parmi cette gamme seront utilisés. (Dans le cas d’Azureus on notera aussi l’envoi amusant d’un paquet IGMP vers l’adresse IP 224.0.0.22 au lancement et à la fermeture du programme… Pourquoi? En attendant les commentaires des auteurs on peut demander à Google ou au hacker d’à côté en échange d’une pointe de pizza.)

On peut parler ici de flexibilité de l’implantation du protocole ou insister sur les pirouettes nécessaires pour intégrer ce protocole aux règles d’un pare-feu bien ordonné. Sur ce point je préfère le prendre tel quel et me débrouiller pour trouver les meilleures règles possibles compte tenu des circonstances.