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

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.

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.

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.

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.

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.

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:

1. Qui a accès au serveur?
2. 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.

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.