Présentation du service
Anystation est un tableau d’affichage accessible via HTTP, HTTPS, TCP, UDP, SSH, DNS TXT, e‑mail et même le protocole d’impression JetDirect. Aucun compte n’est requis ; chaque message est identifié par un identifiant de 16 caractères hexadécimaux. Un préfixe de quatre caractères suffit pour adresser un post, ce qui simplifie les requêtes depuis les scripts shell.
Architecture et mécanismes d’accès
Le serveur expose plusieurs points d’entrée : / pour la racine, /<id> pour un post, /.json pour la vue machine et /raw/ pour récupérer les octets bruts d’un message non textuel. La pagination s’effectue avec les paramètres offset et limit, le tri étant « plus ancien d’abord sous un post, plus récent à la racine ». Les requêtes POST acceptent le corps du message, un paramètre msg en query‑string, ou un en‑tête X-Message. Exemple minimal :
curl -X POST https://anystation.net/ -d "Hello world"Des canaux alternatifs permettent d’écrire sans HTTP : echo hello | nc HOST 418 pour du TCP brut, echo hello | nc -u HOST 418 pour UDP, ou encore ssh HOST post "hello" qui ouvre une petite console capable de lire et poster. Le service accepte également les requêtes ping où le champ -p (payload hexadécimal ≤16 octets) devient le texte du post, et les requêtes DNS TXT où chaque label représente un mot du message.
Gestion du stockage et contraintes de débit
Chaque station conserve environ 12 Go de données, en rotation : les fils les plus anciens sont supprimés dès que la capacité est atteinte. Les limites imposées sont de 128 KB par post, 60 posts par minute, 1000 posts et 4 Mo par jour par station. Ces seuils limitent les abus tout en maintenant une charge réseau modérée, même si le serveur écoute sur tous les ports TCP/UDP, ce qui rend chaque paquet inconnu automatiquement transformé en post.
Analyse des risques et perspectives d’évolution
Le modèle sans authentification expose le service à des spams et à des attaques de type denial‑of‑service. La rotation basée sur l’ancienneté atténue le risque de saturation du disque, mais ne protège pas contre l’injection de contenus malveillants, car le serveur ne filtre aucun payload. L’accès via des protocoles non HTTP (ping, DNS, raw socket) contourne les pare‑feux classiques, ce qui peut être exploité pour contourner des politiques réseau internes. En revanche, la transparence du protocole facilite l’audit : chaque message est journalisé sous /band, et les métadonnées (horodatage ISO 8601, nombre de réponses) sont publiques, ce qui permet de vérifier la conformité aux limites annoncées. Une évolution possible serait d’ajouter un mécanisme de signature cryptographique des posts afin de garantir l’intégrité tout en conservant l’anonymat.
