Lors de la mise en place de mes instances de serveurs virtuels, j'ai besoin que certaines applications soient créées à l'aide de make . Existe-t-il des risques de sécurité liés au fait d'avoir make installée ? Ou dois-je le nettoyer avant que l'instance ne soit déployée ?
J'ai également le gcc sur le serveur que j'utilise pour construire des applications avant de les déployer.
Certains diront que la présence d'outils de développement sur une machine de production facilitera la tâche d'un attaquant. Cependant, il s'agit d'un obstacle si minime pour un attaquant que tout autre argument pour ou contre l'installation d'outils de développement pèsera plus lourd dans la balance.
Si un pirate a pu pénétrer le système au point de pouvoir invoquer les outils présents sur le serveur, il s'agit déjà d'une grave faille de sécurité. Sans outils de développement, il existe de nombreuses autres façons d'écrire des données binaires dans un fichier et 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 sa propre machine et le transférer sur le serveur.
Il y a d'autres éléments beaucoup plus pertinents à surveiller. Si un logiciel installé contient un bogue de sécurité, il y a plusieurs façons de l'exposer à un attaquant :
Je ne m'attends pas à ce que les outils de développement correspondent à l'un des éléments ci-dessus et, en tant que tel, il ne s'agit pas d'un paquet à haut risque.
Si vous avez des flux de travail dans lesquels vous souhaitez utiliser les outils de développement, vous devez d'abord décider s'il s'agit de flux de travail raisonnables et, si c'est le cas, vous devez installer les outils de développement.
Si vous constatez que vous n'avez pas vraiment besoin de ces outils sur le serveur, vous devriez vous abstenir de les installer pour de multiples raisons :
Si vous décidez, pour des raisons de sécurité, de ne pas autoriser les utilisateurs non privilégiés à placer leurs propres exécutables sur le serveur, ce ne sont pas les outils de développement qu'il faut éviter, mais plutôt les répertoires accessibles en écriture à ces utilisateurs sur des systèmes de fichiers montés avec des autorisations d'exécution. Les outils de développement peuvent toujours être utilisés même dans ces circonstances, mais c'est peu probable.
make en soi est très bien. make est simplement un cadre de suivi des dépendances et d'automatisation. Il est typiquement utilisé en conjonction avec des compilateurs, cependant, et ceux-ci ne devraient de préférence pas être disponibles sur un système de production, car ils sont complètement inutiles. Il en va de même pour tous les paquets 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 paquets requis par l'application doivent être présents.
Vous devez construire votre application sur un serveur de construction, l'empaqueter, puis déployer le paquet binaire sur vos systèmes de production.
Note : outils d'emballage natifs aspirer . N'essayez même pas de les comprendre. Consultez plutôt l'article de Jordan Sissel intitulé fpm . L'emballage est un véritable plaisir.
make est un Shell qui a une syntaxe différente de celle de bash .
Un compilateur comme gcc est un puissant awk configuré avec un ensemble de substitutions que les awk ne prend pas en charge. Il s'agit d'un système non conforme à POSIX sort o cat qui injecte des déchets dans la sortie. Il s'agit d'un éditeur de texte interactif (pensez vi ) qui est configuré pour effectuer quelques modifications au démarrage, puis pour quitter avant d'afficher l'interface utilisateur.
Ils n'ont rien d'intrinsèquement insécurisant, ils ne rendent pas votre machine plus insécurisée qu'une machine où vous avez bash +. cat + Shell.
Au contraire, le problème potentiel n'est pas d'avoir make sur le serveur de production, le problème potentiel est de créer les applications sur le serveur de production au lieu de déployer des images pré-construites testées. Il peut y avoir des raisons valables à cette méthodologie, mais je m'y opposerais vigoureusement si on me demandait de l'adopter.
Vous demandez si make devrait être installé sur un serveur de production, mais ma vraie question est la suivante : Qui a accès à ce serveur de production et quelles mesures de protection avez-vous mises en place pour faire face à une incursion ? Si make n'a pas été installé mais quelqu'un a gagné root l'accès, devinez quoi ? Ils peuvent installer manuellement make et tout ce qu'ils veulent.
La dure réalité de la sécurité informatique est que, même si vous souhaitez empêcher les accès non désirés, il n'est pas aussi important d'être obsédé par le blocage de l'accès que de le faire :
Tout dépend du type de travail que vous effectuez. Je travaille principalement dans le domaine des serveurs web et mon attitude est la suivante : toute personne qui obtient de moi un accès à un serveur de production doit prouver ses compétences, ses connaissances et sa maturité. C'est tout. Parfois, cela prend quelques jours. Parfois, cela prend des mois. Mais fondamentalement, votre meilleure ligne de sécurité sur les serveurs de production est le contrôle de l'accès en plus des diverses autres choses que nous faisons pour durcir les serveurs.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
