🔒 Sécurité Gitea : exposé Internet ? Risques + check

Ce que signifie la présence du port 3000

Les 66 857 résultats associés au port 3000 correspondent à environ 58 % des instances repérées par l'empreinte de l'application. Dans cette collecte, une majorité des réponses identifiées apparaît donc sur le port par défaut documenté de Gitea.

Le reste peut être sur un autre port, passer par un mandataire inverse sur le port 443, partager un point d'entrée avec d'autres applications ou dépendre d'une configuration personnalisée. En clair : ne regarder que le port 3000 fait forcément rater une partie des services potentiellement concernés. Et inversement, voir une page sur ce port ne suffit pas à conclure que des données sont exposées ou qu'il y a une faille.

Une empreinte n'est pas un diagnostic de sécurité

Un moteur de recherche spécialisé observe des services joignables et les classe à partir d'indices techniques. Il ne sait pas, à lui seul, si l'inscription est ouverte, si les dépôts sont privés, quelle version est installée, ou si les règles d'accès sont appliquées correctement.

Il faut donc lire ces nombres comme une estimation de la surface visible, pas comme un décompte de serveurs compromis. Ils aident à poser une question opérationnelle - « est-ce qu'il y a une instance exposée que nous n'avons pas inventoriée ? » - mais ils ne répondent pas à la question centrale : « cette instance permet-elle un accès non autorisé ? ».

Le code source donne du contexte, pas seulement des fichiers

Un dépôt peut révéler l'architecture d'une application, des dépendances, des noms de services internes, des conventions de déploiement, voire des informations laissées par inadvertance dans l'historique. Même sans secret directement exploitable, ce contexte peut aider à préparer une attaque ou exposer des éléments que l'organisation pensait garder confidentiels.

Un dépôt public peut parfaitement être volontaire. Le problème arrive quand le réglage observé ne correspond pas à la décision de l'équipe : dépôt censé rester privé rendu visible, règle censée s'appliquer à tous les nouveaux dépôts qui ne l'est pas réellement, etc.

Les pipelines rapprochent le dépôt de la production

Les automatisations de construction et de déploiement peuvent utiliser des variables contenant des jetons, des clés ou des identifiants techniques. Tout dépend des permissions, des conditions de déclenchement et de la protection des journaux.

Un secret « masqué » dans une sortie standard reste préoccupant s'il peut être accessible par un processus non fiable, ou si son utilisation est trop largement permise à des pipelines. Gitea Actions permet d'exécuter des workflows. Le fait que l'instance ait cette brique ne veut pas dire qu'on y trouve forcément des identifiants de production, mais ça justifie de vérifier où les secrets sont stockés, qui peut modifier les workflows et dans quelles conditions ils s'exécutent. La documentation officielle présente le fonctionnement de Gitea Actions.

Les comptes et les dépôts forment un même système d'accès

Une politique d'inscription mal calibrée peut autoriser des utilisateurs non prévus à créer un compte. Un compte n'accorde pas automatiquement l'accès à tous les dépôts : les permissions et la visibilité restent déterminantes. Mais si l'inscription est trop ouverte, elle devient le premier maillon d'un problème plus large.

C'est pour ça qu'il faut regarder ensemble les paramètres d'authentification, les règles d'inscription, les rôles et la visibilité des dépôts. Gitea détaille les options d'authentification et les paramètres dans le guide de configuration.

1. Confirmer l'inventaire et le besoin d'exposition

Commencez par lister les instances que vous connaissez : nom d'hôte, environnement, équipe responsable, version, mode d'hébergement et présence (ou non) d'un mandataire inverse. Ensuite, complétez avec les services détectés par vos outils, vos fournisseurs d'infrastructure et vos équipes de développement.

Pour chaque instance, posez trois questions :

• Est-elle censée être accessible depuis Internet, ou un accès par réseau privé / relais sécurisé suffit-il ?
• Qui est responsable de la mise à jour et de la configuration ?
• Existe-t-il une procédure de récupération, et un moyen de savoir si le service a changé ou est tombé ?

Sans propriétaire identifié, une instance est difficile à maintenir et à sécuriser. Si l'accès public est nécessaire, documentez la raison et les contrôles qui rendent la décision acceptable. Sinon, réduire l'exposition réseau est souvent plus efficace que d'empiler des exceptions applicatives.

2. Vérifier l'inscription, l'authentification et les droits

Vérifiez si l'inscription libre est activée et si elle colle à la politique de l'organisation. Pour une forge interne, l'accès passe généralement par une identité maîtrisée, selon le modèle d'authentification choisi. Passez aussi en revue les comptes inactifs, les comptes d'administration et les droits attribués aux équipes.

L'authentification centralisée aide parfois, mais elle ne corrige pas automatiquement des permissions trop permissives côté Gitea. L'idéal est de tester le parcours avec plusieurs profils : administrateur, membre standard et utilisateur qui ne devrait pas avoir accès. Cherchez le résultat réel, pas uniquement « ce qui est censé être réglé ».

Contrôlez séparément :

• les règles d'inscription et de validation des nouveaux comptes ;
• les méthodes d'authentification autorisées ;
• les droits des administrateurs et des responsables d'organisation ;
• la révocation des comptes quand une personne quitte l'équipe ;
• la visibilité des dépôts, groupes et organisations.

3. Examiner les dépôts et leurs paramètres de visibilité

Ne vous limitez pas à vérifier quelques projets « connus ». Définissez les règles attendues pour les nouveaux dépôts, puis vérifiez les exceptions déjà existantes. Faites particulièrement attention aux dépôts qui contiennent du code de déploiement, des exemples de configuration ou de la documentation interne.

Un dépôt public peut être légitime : bibliothèques, outils réutilisables, projets open source. La revue doit donc distinguer « choix assumé » et « exposition accidentelle ».

Si un dépôt a été rendu public par erreur, repasser en privé ne suffit pas forcément : des copies existent peut-être déjà (clones, téléchargements, consultations). Il faut alors regarder l'historique et changer les identifiants qui auraient pu être divulgués.

4. Réduire la portée des secrets et des automatisations

Commencez par inventorier les secrets utilisés par les workflows : fonction, propriétaire, environnement et permissions associées. Donnez à chaque identifiant le périmètre minimal nécessaire. Un jeton capable de publier un artefact ne devrait pas, juste « par confort », disposer de droits d'administration sur toute la forge.

Ensuite, vérifiez qui peut modifier les workflows, quelles branches ou contributions déclenchent leur exécution, et si les environnements de déploiement imposent une approbation. Allez aussi vérifier les journaux pour vous assurer que les valeurs sensibles ne ressortent pas. Le masquage est une sécurité supplémentaire, pas une stratégie de gestion des secrets.

En cas de doute, ne faites pas que retirer une valeur d'un fichier ou d'un log. Révoquez (ou renouvelez) le secret concerné, cherchez où il est utilisé dans les dépôts et les historiques, puis vérifiez ce qui a été fait avec l'identité associée.

5. Séparer les identités d'administration et d'automatisation

Un compte utilisé par une personne pour administrer la forge ne doit pas être confondu avec un compte technique utilisé par un pipeline. Ces identités n'ont ni le même rôle, ni le même cycle de vie, ni les mêmes besoins.

Séparer facilite la révocation et l'analyse des événements. Ça évite aussi qu'un compte humain privilégié se retrouve intégré dans une automatisation, ou qu'un compte technique reçoive un accès interactif inutile. Associez chaque identité à un responsable, documentez ses permissions et supprimez ce qui n'est plus nécessaire.

Transformer un chiffre global en vérification locale

Pour une équipe, l'approche utile consiste à partir de ses propres actifs, plutôt que d'essayer de déduire une conclusion « mondiale » d'un nombre brut. Une démarche pragmatique tient en quatre étapes :

1. Recenser les instances connues et celles détectées par vos contrôles internes.
2. Qualifier leur exposition, leur responsable et leur usage métier.
3. Tester l'inscription, les accès, la visibilité des dépôts et les permissions des automatisations.
4. Corriger et suivre les écarts, puis intégrer ces contrôles au processus de création et de mise à jour des instances.

Priorisez d'abord les cas où une instance est exposée sans responsable clair, où l'inscription n'est pas maîtrisée, ou où des pipelines disposent de droits trop étendus. Ce sont des signaux vraiment actionnables. Le fait qu'un service écoute sur le port 3000 aide à le repérer, mais ça ne devrait pas être le seul indicateur de gravité.

La bonne question n'est donc pas : « combien de Gitea sont visibles dans le monde ? ». C'est plutôt : « savons-nous lesquels nous exploitons, pourquoi ils sont accessibles, et ce qu'un compte ou un pipeline peut réellement faire ? ». Cette nuance évite autant la panique face à un chiffre que la fausse assurance d'une configuration supposée sûre.