Est-il sécuritaire qu'un serveur de production se soit installé?

42

Lors de la configuration de mes instances de serveur virtuel, certaines applications doivent être construites à l'aide de make. Existe-t-il des risques de sécurité associés à l' makeinstallation? Ou devrais-je le nettoyer avant le déploiement de l'instance?

J'ai également le gcccompilateur sur le serveur que j'utilise pour créer des applications avant le déploiement.

security make gcc

— SK '
source

4

Si vous vous sentez mieux, tout logiciel installé n’importe où crée une vulnérabilité.

— MDMoore313

1

Et l’un avec un accès shell non-root à un serveur pourrait télécharger un package de compilateur "indépendant de la distro" (.tar.gz) qui n’aura pas besoin d’être installé de manière ...

1

Est-ce moi, ou est la combinaison de "est-ce sécuritaire?" et "accès root" plutôt inconfortable ?

— ADN

2

Si vous avez déjà installé gcc, il n’ya pratiquement aucun moyen d’empirer tout problème de sécurité potentiel.

— Shadur

1

@Shadur Quelle différence le fait d'avoir GCC? Si l'utilisateur a déjà accès à la machine, il peut télécharger n'importe quelle copie de gcc de manière triviale. Quoi qu'il en soit, gcc peut être utile aux utilisateurs sans privilèges et ne pas représenter un risque pour la sécurité tant qu'aucun utilisateur privilégié ne l'exécute.

— Vality

50

Certains diront que la présence d'outils de développement sur une machine de production facilitera la vie des attaquants. Cependant, il s’agit là d’une si petite route pour un attaquant que tout autre argument que vous pourrez trouver pour ou contre l’installation des outils de développement pèsera plus lourd.

Si un attaquant parvient jusqu'à présent à pénétrer dans le système et à invoquer tous les outils présents sur le serveur, vous êtes déjà victime d'une grave atteinte à la sécurité. Sans outils de développement, il existe de nombreuses autres manières d'écrire des données binaires dans un fichier, puis d'exécuter un chmod sur ce fichier. Un attaquant souhaitant utiliser un exécutable personnalisé sur le système à ce stade pourrait tout aussi bien le construire sur son propre ordinateur et le transférer sur le serveur.

Il y a d'autres choses beaucoup plus pertinentes à surveiller. Si un logiciel installé contient un bogue de sécurité, il peut être exposé à un attaquant de plusieurs manières:

Le paquet peut contenir un exécutable suid ou sgid.
Le paquet pourrait être des services de démarrage sur le système.
Le paquet peut installer des scripts invoqués automatiquement dans certaines circonstances (cela inclut les tâches périodiques, mais les scripts peuvent être invoqués par d'autres événements, par exemple lorsque l'état d'une interface réseau change ou lorsqu'un utilisateur se connecte).
Le paquet pourrait installer des inodes de périphérique.

Je ne m'attendrais pas à ce que les outils de développement correspondent à l'un des éléments ci-dessus et, en tant que tel, n'est pas un paquet à haut risque.

Si vous avez des workflows dans lesquels vous utiliseriez des outils de développement, vous devez d'abord déterminer si ces workflows sont raisonnables et, le cas échéant, vous devez installer les outils de développement.

Si vous constatez que vous n'avez pas vraiment besoin de ces outils sur le serveur, évitez de les installer pour plusieurs raisons:

Économise de l'espace disque, à la fois sur le serveur et sur les sauvegardes.
Moins de logiciels installés facilitent le suivi de vos dépendances.
Si vous n’avez pas besoin du progiciel, il n’ya aucun intérêt à prendre le risque de sécurité supplémentaire lié à son installation, même si le risque de sécurité est minime.

Si vous décidez que, pour des raisons de sécurité, vous n'autoriserez pas les utilisateurs non privilégiés à placer leurs propres étiquettes d'exécution sur le serveur, vous devez éviter les outils de développement, mais plutôt les répertoires accessibles en écriture aux utilisateurs des systèmes de fichiers montés avec des autorisations d'exécution. Même dans ces circonstances, les outils de développement peuvent toujours être utiles, mais ce n’est pas très probable.

— Kasperd
source

6

J'ajouterais à cela qu'un certain nombre de systèmes de production reposent sur du code interprété (par exemple, PHP, Perl, Python, ...). Interdire les outils de développement dans ce contexte n'aurait aucun sens. Je considérerais les compilateurs comme gccne pas présenter un risque plus élevé que ceux-ci. Comme vous le dites, un attaquant en mesure d'utiliser les compilateurs installés sur un système serait généralement en mesure de faire des choses pires de toute façon, telles que le téléchargement de son propre exécutable (éventuellement lié statiquement).

— Bruno

3

Pertinent: Une version minuscule de wget (51 octets?) . Un exemple concret d'un attaquant déplaçant un fichier binaire sur le serveur à l'aide d' echoinstructions ultérieures dans un fichier. L'ensemble du processus est automatisé avec un script trouvé dans le même lien.

— Adi

2

@Adnan, intéressant. Autant que je sache, le principal défaut de sécurité de cet exemple de DVR est le fait que l'attaquant peut se connecter à telnet en tant que root avec le mot de passe 123456 en premier lieu. Avoir ou ne pas avoir wget ou d'autres outils (avant l'attaque) est alors à peine pertinent.

— Bruno

15

makeest un shell qui a une syntaxe différente de celle de bash.

Un compilateur comme gccest un puissant awkconfiguré avec un ensemble de substitutions que standard awkne supporte pas. C'est un non-conforme à POSIX sortou catqui injecte des déchets dans la sortie. Il s'agit d'un éditeur de texte interactif (think vi) configuré pour effectuer certaines modifications au démarrage, puis quitter avant d'afficher l'interface utilisateur.

Il n’ya rien d’insécurité intrinsèque en eux, ils ne rendent pas votre machine plus incertaine que celle où vous avez une catredirection bash + shell.

— Ignis
source

2

Une réponse si zen que je ne sais pas comment le noter.

— Kasperd

4

@kasperd Cette réponse se veut sérieuse. Je pensais qu'apporter le point de vue d'un programmeur pourrait être utile. Une fonction qui traduit une entrée en une sortie n'introduit pas de vulnérabilité simplement parce que sa sortie est dans un format compréhensible pour la CPU.

— lundi

1

Je suis d'accord avec le point que vous faites. Je pense que votre réponse est une excellente lecture pour tous ceux qui sont déjà d’accord avec elle. Je crains seulement que votre réponse ne soit une blague pour quelqu'un qui n'est pas d'accord avec cela.

— Kasperd

J'aime cette réponse beaucoup plus que celle acceptée :)

— Ruslan

15

makelui-même va bien. makeest simplement un cadre de suivi et d’automatisation de la dépendance. Il est généralement utilisé avec des compilateurs, mais ceux-ci ne devraient de préférence pas être disponibles sur un système de production, car ils ne sont absolument pas nécessaires. Il en va de même pour tous les packages inutiles, qu'il s'agisse de bibliothèques partagées, d'interprètes, etc. Les logiciels installés sur les systèmes de production doivent être strictement contrôlés et seuls les packages requis par l'application doivent être présents.

Vous devez créer votre application sur un serveur de compilation, la conditionner, puis déployer le package binaire sur vos systèmes de production.

Remarque: les outils de packaging natifs sont nuls . Ne même pas la peine d'essayer de les saisir. Au lieu de cela, consultez Jordan Sissel fpm. Cela fait de l'emballage une joie absolue.

— EEAA
source

8

Je demande par curiosité et par ignorance: pourquoi dites-vous que la présence de compilateurs est un "problème de sécurité important?" Quel est le problème de sécurité avec un compilateur installé? Est-ce juste une question que vous ne devriez pas créer votre code sur un serveur de production et donc que le compilateur est superflu, ou y a-t-il réellement un problème de sécurité important avec la présence du compilateur lui-même?

— Reirab

11

Bien qu'il soit judicieux de créer vos applications sur un serveur distinct, affirmer que la présence de compilateurs sur un système de production est un problème de sécurité important n'a pas de sens. Qu'en est-il des langages de script et des systèmes compilés par JIT (Perl, Python, Java, ...)?

— Bruno

3

La présence de compilateurs dans un environnement de production ne constitue pas un "risque de sécurité important". J'ai moi-même déplacé des fichiers binaires vers des boîtes compromises à l'aide de echoet base64. En fait, vous pouvez même le faire avec une série d’ echoénoncés sans autre outil .

— Adi

1

Bons points, tous. J'ai modifié ma réponse pour clarifier.

— EEAA

9

Au contraire, le problème potentiel n’est pas d’avoir makesur le serveur de production, mais plutôt de créer les applications sur le serveur de production au lieu de déployer des images prédéfinies testées. Il existe peut-être des raisons valables à cette méthodologie, mais c’est une raison contre laquelle j’arguerais énergiquement si on me demandait de l’adopter.

— John
source

4

Vous demandez si vous makedevriez installer le serveur de production, mais ma vraie question serait: qui a accès à ce serveur de production et quelles sont les protections en place pour faire face à une incursion? Si maken'a pas été installé mais que quelqu'un y ait rootaccès, devinez quoi? Ils peuvent installer manuellement makeet tout ce qu'ils veulent.

La dure réalité à propos de la sécurité informatique réside dans le fait que vous souhaitez empêcher tout accès indésirable, être obsédé par le blocage de l'accès n'est pas aussi important que:

Qui a accès au serveur?
Que pouvez-vous faire pour revenir en arrière après une effraction?

Tout dépend du type de travail que vous effectuez. Je travaille principalement dans le monde des serveurs Web et mon attitude est la suivante: quiconque obtient de moi un accès au serveur de production doit prouver ses compétences, ses connaissances et sa maturité. C'est ça. Parfois cela prend quelques jours. Parfois cela prend des mois. Mais fondamentalement, votre meilleure ligne de sécurité sur les serveurs de production consiste à contrôler l’accès, en plus des tâches diverses que nous faisons pour renforcer les serveurs.

— JakeGould
source

1

makelui-même est inoffensif. Tout ce qu'il fait est d'exécuter des applications dans un ordre défini, en fonction des dépendances que vous spécifiez et des fichiers existants dans le système. Cela peut même être utile dans le cadre du processus d’installation: vous pouvez l’utiliser pour placer les fichiers prédéfinis à la place voulue, ou exécuter des tests unitaires, etc.

Cependant, vous devez vous demander à quoi exactement vous voulez vous en servir. Il est souvent utilisé avec des compilateurs et d’autres outils pour créer des applications, et ceux-ci pourraient être utilisés pour annuler certaines de vos lignes de défense. Mais makene peut pas faire ces choses si les outils ne sont pas disponibles.

— Le Spooniest
source