7. Considérations de sécurité
- Considérations de sécurité
Il existe des risques importants à permettre à des clients arbitraires d'établir un tunnel vers des cibles arbitraires, car cela pourrait permettre à des acteurs malveillants d'envoyer du trafic et de le faire attribuer au proxy UDP. Les serveurs HTTP qui prennent en charge le relais UDP devraient restreindre son utilisation aux utilisateurs authentifiés.
Il existe des déploiements logiciels et réseau qui effectuent des contrôles d'accès basés sur l'adresse IP source des demandes entrantes. Par exemple, certains logiciels autorisent les modifications de configuration non authentifiées si elles proviennent de 127.0.0.1. Un tel logiciel pourrait s'exécuter sur le même hôte que le proxy UDP ou dans le même domaine de diffusion. Le trafic UDP relayé serait alors reçu avec une adresse IP source appartenant au proxy UDP. Si cette adresse source est utilisée pour le contrôle d'accès, les clients de proxy UDP pourraient utiliser le proxy UDP pour élever leurs privilèges d'accès au-delà de ceux qu'ils auraient autrement. Cela pourrait conduire à un accès non autorisé par des clients de proxy UDP, à moins que le proxy UDP n'interdise les demandes de proxy UDP vers des cibles vulnérables, telles que les propres adresses du proxy UDP et les adresses localhost, de liaison locale, de multidiffusion et de diffusion. Les proxys UDP peuvent utiliser le type d'erreur de proxy destination_ip_prohibited de la section 2.3.5 de [PROXY-STATUS] lors du rejet de telles demandes.
Les proxys UDP partagent de nombreuses similitudes avec les proxys TCP CONNECT lorsqu'on les considère comme une infrastructure d'abus pour permettre des attaques par déni de service (DoS). Les deux peuvent masquer l'adresse source de l'attaquant de la cible de l'attaque. Dans le cas d'une attaque volumétrique sans état (par exemple, une inondation TCP SYN ou une inondation UDP), les deux types de proxys transmettent le trafic à l'hôte cible. Avec des attaques volumétriques avec état (par exemple, une inondation HTTP) envoyées via un proxy TCP CONNECT, le proxy n'enverra des données que si la cible a indiqué sa volonté d'accepter des données en répondant avec un TCP SYN-ACK. Une fois le chemin vers la cible inondé, le proxy TCP CONNECT ne recevra plus de réponses de la cible et cessera d'envoyer des données. Comme UDP n'établit pas d'état partagé entre le proxy UDP et la cible, le proxy UDP pourrait continuer à envoyer des données à la cible dans une telle situation. Bien qu'un proxy UDP puisse potentiellement limiter le nombre de paquets UDP qu'il est prêt à transférer jusqu'à ce qu'il ait observé une réponse de la cible, cela offre une protection limitée contre les attaques DoS lorsque les attaques ciblent des ports UDP ouverts où le protocole fonctionnant sur UDP répondrait et cela serait interprété comme une volonté d'accepter UDP par le proxy UDP. Une telle limite de paquets pourrait également causer des problèmes pour le trafic valide.
Les considérations de sécurité décrites à la section 4 de [HTTP-DGRAM] s'appliquent également ici. Comme il est possible de tunneliser des paquets IP sur UDP, les conseils de [TUNNEL-SECURITY] peuvent s'appliquer.