Intégration de Tor dans RouterOS : Mise en œuvre d’un Proxy SOCKS Isolé via Containers

Mikrotik TOR

1. Contexte et objectif architectural

Avec l’introduction du support des containers Docker dans RouterOS v7, MikroTik a changé de catégorie : le routeur n’est plus seulement un équipement de transit, il devient une plateforme d’exécution réseau sécurisée.

L’objectif ici est de :

  • Déployer un client Tor dans un container isolé

  • Exposer un proxy SOCKS v5

  • Garantir une séparation stricte des plans de trafic

  • Offrir un point de sortie anonymisé pour des applications ou navigateurs spécifiques

Le tout sans polluer le plan de gestion du routeur et en respectant les bonnes pratiques L2/L3 et firewall.

2. Pré-requis techniques

Avant de continuer, le routeur doit répondre à ces critères :

  • RouterOS v7.x (support containers)

  • Stockage persistant disponible (disk1)

  • Accès Internet fonctionnel côté WAN

  • Accès physique au routeur (obligatoire pour activer le mode container)

Étape 1 : Initialisation du mode Container (Device Mode)

RouterOS protège volontairement certaines fonctionnalités sensibles. Le moteur container fait partie des fonctions verrouillées par défaut.

/system/device-mode/update container=yes

Ce qu’il se passe réellement

  • Le routeur bascule en mode étendu

  • Un reboot est exigé

  • Une confirmation physique via le bouton Reset est requise

Ce mécanisme empêche toute activation distante malveillante. Une fois le routeur redémarré, le runtime container est disponible.

Étape 2 : Création d’une infrastructure réseau isolée

Tor ne doit jamais partager le même segment que l’administration du routeur.
On met donc en place une zone réseau dédiée, avec son propre plan d’adressage.

2.1 Création du bridge Tor

/interface bridge add name=bridge-tor comment="Tor Container Bridge"

Ce bridge agit comme un switch virtuel interne entre RouterOS et le container.

2.2 Création de l’interface VETH

/interface veth add \
  name=veth-tor-client \
  address=172.17.0.2/24 \
  gateway=172.17.0.1

L’interface VETH est l’équivalent d’une carte réseau virtuelle Docker, mais gérée nativement par RouterOS.

2.3 Rattachement au bridge

/interface bridge port add bridge=bridge-tor interface=veth-tor-client

2.4 Configuration de la passerelle côté RouterOS

/ip address add \
  address=172.17.0.1/24 \
  interface=bridge-tor \
  comment="Gateway for Tor Container"

Résultat :

  • RouterOS = passerelle

  • Container Tor = client isolé

  • Aucun lien direct avec le LAN ou le plan de management

Étape 3 : Pare-feu et NAT (sortie vers Internet)

Sans NAT, Tor ne pourra jamais atteindre les Entry Nodes du réseau Onion.

3.1 NAT sortant

/ip firewall nat add \
  chain=srcnat \
  src-address=172.17.0.0/24 \
  action=masquerade \
  comment="NAT for Tor Container"

Ici, le container sort sur Internet comme n’importe quel hôte interne, mais sans exposition directe.

3.2 Filtrage optionnel : accès SOCKS depuis le LAN

/ip firewall filter add \
  chain=forward \
  src-address=192.168.88.0/24 \
  dst-address=172.17.0.2 \
  dst-port=9050 \
  protocol=tcp \
  action=accept \
  comment="Allow LAN to Tor SOCKS"

Bonne pratique :

  • Limiter les sources

  • Ne jamais exposer le port SOCKS sur le WAN

  • SOCKS ≠ service public

Étape 4 : Déploiement du container Tor

4.1 Configuration du registre Docker

/container config set \
  registry-url=https://registry-1.docker.io \
  tmpdir=disk1/pull

RouterOS agit ici comme un client Docker minimaliste.

4.2 Variables d’environnement

/container envs add \
  name=tor_env \
  key=TORSOCK_ALLOW_INBOUND \
  value=1

Cette variable permet au service Tor d’écouter sur toutes les interfaces du container, condition indispensable pour exposer le SOCKS.

4.3 Création du container

/container add \
  remote-image=goldy/tor-client \
  interface=veth-tor-client \
  root-dir=disk1/tor-root \
  envlist=tor_env \
  logging=yes

Points importants :

  • root-dir assure la persistance

  • logging=yes facilite le debug Tor

  • Le container est directement attaché au VETH

Étape 5 : Lancement et monitoring

5.1 Démarrage

/container start [find where remote-image~"tor"]

5.2 Vérification de l’état

/container print

L’état attendu est running.

5.3 Analyse des logs Tor

/log print where topics~"container"

Indicateurs clés :

  • Connexion aux directory servers

  • Bootstrapping à 100 %

  • Circuits établis

Quand Tor parle beaucoup dans les logs, c’est généralement bon signe.

Résumé technique – Proxy SOCKS Tor

  • IP du proxy : 172.17.0.2

  • Port : 9050

  • Type : SOCKS v5

  • Usage : navigateur, outil de pentest, client API, application spécifique

Configuration côté client :

SOCKS5 → 172.17.0.2:9050

Conclusion opérationnelle

Cette architecture transforme un routeur MikroTik en point d’anonymisation réseau contrôlé, sans VM, sans serveur dédié, et avec une isolation propre.

Ce n’est pas un gadget.
C’est un pattern d’architecture réutilisable : Tor aujourd’hui, IDS, honeypot ou agent IA demain. Le routeur devient un nœud intelligent du réseau.

Le futur des équipements réseau ne sera pas passif.
Il sera containerisé, cloisonné, et programmable.



Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Qu’est-ce que le démarrage réseau (PXE) et comment l’utiliser?

Image
I. Présentation Dans cet article, nous allons parler du boot PXE ainsi que du boot iPXE , deux notions essentielles à connaître en tant qu’administrateur système et réseau. Elles sont directement liées à un processus incontournable pour les entreprises : le déploiement de postes de travail . Traditionnellement, lorsqu'on souhaite installer un système d’exploitation sur un poste de travail, on utilise une clé USB sur laquelle on a préalablement copié l’image ISO du système. Une fois cela fait, on connecte physiquement la clé à l’ordinateur, qui charge son contenu afin de lancer l’installation. De manière similaire, bien que plus rare aujourd’hui, on peut également utiliser un CD ou un DVD d’installation, mais là encore, il faut disposer d’un support physique. Grâce au boot PXE ou iPXE , il est possible de s’affranchir de l’utilisation de ces supports physiques, car le démarrage se fait à travers le réseau . Si vous débutez en informatique et que vous souhaitez comprendre le fon...
Lire la suite

RRU dans l'architecture GSM : Tout en détail

Image
Le RRU : Un composant clé de l’architecture GSM Aujourd’hui, nous abordons l’un des éléments essentiels de l’architecture GSM : le Remote Radio Unit (RRU) . Ce module joue un rôle fondamental dans la transmission radio entre les terminaux mobiles et le réseau, assurant la qualité et la fiabilité des communications mobiles. 1. Fonctionnement du RRU Le RRU agit comme une interface radio déportée du BTS (Base Transceiver Station) , située à proximité des antennes, et traite les signaux radio avec une grande précision. Son fonctionnement peut être résumé en plusieurs étapes techniques : 1.1. Réception du signal radio émis par le terminal mobile Le terminal mobile émet un signal radio modulé en fréquence ou amplitude selon la norme GSM. Ce signal est capté directement par l’antenne connectée au RRU. Le RRU amplifie le signal faible reçu via un Low Noise Amplifier (LNA) pour améliorer le rapport signal/bruit. Ensuite, le signal analogique est converti en signal numérique à l...
Lire la suite

Implémentation d’une architecture IP/MPLS chez Orange RDC avec des équipements MikroTik : une révolution technique potentielle au cœur de la connectivité nationale

Image
Contexte et Objectifs Face à la croissance exponentielle du trafic de données, aux défis de couverture dans les zones rurales reculées, et à la demande croissante de services à valeur ajoutée (VPN d'entreprise, Qualité de Service garantie, segmentation réseau avancée, haute disponibilité), Orange RDC devrait choisir  d'adopter une architecture IP/MPLS. Cette transition va permettre  à construire une infrastructure réseau robuste, agile et hautement scalable, en s'appuyant sur la flexibilité et l'abordabilité des équipements MikroTik de dernière génération. Les objectifs principaux de cette initiative sera  multiples et couvrira  des aspects critiques de la transformation numérique d'Orange RDC : Modernisation de l'infrastructure backbone IP : Orange  passerai  d'une architecture IP traditionnelle à un backbone IP/MPLS de pointe pour optimiser le routage et la gestion du trafic. Offre de services convergents : Il s'agira de fournir une suite complète d...
Lire la suite