Est-ce que l'exécution de la mise à niveau apt-get est assez fréquente pour assurer la sécurité d'un serveur Web?
Hypothèses:
- Serveur Web LAMP normal exécutant une application Web. (Par exemple, AWS EC2 + Apache2 + MySQL + Php7)
- Pas directement ciblé par un super-hacker ou une organisation gouvernementale, etc.
- En lien avec le point ci-dessus, aucune ingénierie sociale et l'application Web elle-même ne sont sécurisées.
Ciblé par qui?
Analyses et exploits automatisés. Y en a-t-il d'autres?
Est en cours d'exécution apt-get update && apt-get upgrade de temps en temps suffisamment pour sécuriser un serveur Web?
Sinon
Que devrait faire le programmeur d'applications Web "moyen", qui s'occupe également du serveur, pour garder le serveur Web raisonnablement sûr pour une entreprise en démarrage.
Ça dépend...
Oui, cela dépend toujours de beaucoup de choses. Veuillez inclure des hypothèses pour les cas les plus courants (principe de Pareto) dont le programmeur d'application Web courant peut ou non avoir connaissance.
Vous avez supprimé de nombreux problèmes qui vous causent normalement des ennuis (à savoir, en supposant que l'application que vous hébergez est complètement sécurisée). D'un point de vue pratique, vous devez absolument les considérer.
Mais sans doute puisque vous en êtes conscient, vous avez mis en place des mesures de protection. Parlons du reste, alors.
Pour commencer, vous ne devriez probablement pas exécuter une mise à jour "de temps en temps". La plupart des distributions exploitent des listes de diffusion d'annonces de sécurité, et dès qu'une vulnérabilité y est annoncée, elle est plutôt publique (enfin, c'est souvent avant cela, mais dans votre situation, vous ne pouvez pas vraiment surveiller toutes les listes de sécurité dans le monde). Ce sont des listes à faible trafic, vous devez donc vraiment vous abonner à votre distribution et effectuer une mise à niveau lorsque vous en recevez des notifications.
Souvent, un serveur entretenu de manière nonchalante peut être forcé par une force brute ou attaqué par un dictionnaire sur une longue période, car le responsable ne recherche pas vraiment les signes. C'est donc une bonne idée d'appliquer les contre-mesures habituelles - pas d'authentification par mot de passe ssh, fail2ban sur ssh et Apache - et idéalement de configurer des alertes de surveillance en cas d'activité suspecte. Si cela ne fait pas partie de votre budget de maintenance (temps), prenez l'habitude de vous connecter régulièrement pour vérifier ces choses manuellement.
Bien que cela ne soit pas traditionnellement considéré comme une partie de la sécurité, vous voulez vous assurer que vous pouvez mettre en place un nouveau serveur rapidement. Cela signifie que les scripts de configuration du serveur (des outils comme Ansible, Chef, etc. sont de toute façon utiles dans l'administration du système) et un système de sauvegarde automatique que vous avez testé. Si votre serveur a été piraté, vous devez supposer qu'il est compromis pour toujours et l'effacer, et cela craint si vous n'avez pas effectué de sauvegardes régulières de vos données.
Il y a de fortes chances que vous gardiez le serveur principalement sécurisé si vous exécutez souvent des mises à jour (c'est-à-dire au moins quotidiennement, au lieu de "de temps en temps") .
Mais, des bogues critiques se produisent de temps en temps, comme Shellshock ou ImageTragick . Une configuration de serveur non sécurisée peut également rendre les attaques possibles. Cela signifie que vous devez également prendre plus d'actions que de simplement exécuter des mises à jour régulières, comme:
- réduire la surface d'attaque en exécutant un système minimal, c'est-à-dire ne pas installer de logiciel inutile
- réduire la surface d'attaque en restreignant tous les services accessibles de l'extérieur, c'est-à-dire ne pas autoriser la connexion SSH basée sur un mot de passe (uniquement basée sur une clé), ne pas exécuter de services inutiles, etc.
- assurez-vous de bien comprendre l'impact des mises à jour critiques
- attendez-vous à ce que le système soit attaqué et essayez de réduire l'impact, par exemple en exécutant des services accessibles de l'extérieur à l'intérieur d'un chroot, d'une prison ou d'un conteneur
- enregistrer des événements importants comme les échecs de connexion, comprendre les journaux et analyser réellement les journaux
Pourtant, le vecteur d'attaque initial le plus utilisé est probablement les applications Web non sécurisées comme Wordpress ou autre CMS. Mais votre hypothèse était que l'application Web est entièrement sécurisée, alors j'espère que c'est vraiment le cas.
La plupart des distributions Linux modernes sont livrées avec une sorte de solution de mise à jour automatique. Vous devriez envisager de l'activer sur vos serveurs. Cela réduira considérablement le temps que votre serveur est vulnérable aux attaques.
Comme vous parlez de Debian, vous devriez envisager de configurer mises à niveau sans assistance . RedHat a yum-cron, et Suse peut les obtenir via YaST.
Ces mises à niveau sont normalement limitées aux correctifs de sécurité et ne risquent pas de briser votre système, mais ce n'est pas totalement impossible. En fin de compte, c'est à vous de pondérer les risques et les avantages de cette approche.
apt-get upgrade installe uniquement les versions les plus récentes des packages déjà installés. Il n'installe pas les packages qui ne sont pas actuellement installés et il ne mettra pas à niveau un package déjà installé si la version la plus récente dépend d'un package qui n'est pas actuellement installé.
Dans Debian et Ubuntu, chaque version du noyau est placée dans un paquet séparé, avec la version incluse dans son nom. En outre, il existe un package virtuel qui dépend toujours du dernier noyau disponible, la dépendance étant modifiée avec chaque version. Par exemple, comme pour l'instant linux-image-generic dans xenial dépend de linux-image-4.4.0-63-generic. Ce schéma permet aux anciennes versions des noyaux de rester installées, et au cas où la nouvelle se révélerait incompatible avec votre matériel.
Cependant, cela signifie que apt-get upgrade n'installera pas de noyaux plus récents - vous avez besoin de apt-get dist-upgrade pour ça. Cependant, de nombreuses personnes évitent de l'utiliser automatiquement car elles peuvent également supprimer des packages. Dans les versions plus récentes d'Ubuntu, vous pouvez utiliser apt upgrade, qui installe de nouvelles dépendances, mais ne supprime jamais aucun paquet.
De plus, lorsque vous mettez à niveau OpenSSL, vous devez au moins recharger les services qui utilisent cette bibliothèque; dans Ubuntu, le système demande simplement que le redémarrage reste du bon côté, et de nombreuses personnes ont également des réserves contre les redémarrages automatiques.
Il y a déjà de bonnes réponses ici. Cependant, je voulais combler certaines lacunes et souligner quelques points qui ne semblent pas être abordés dans certaines des réponses existantes.
Pas directement ciblé par un super-hacker ou une organisation gouvernementale, etc.
C'est une perspective dangereuse. De nombreuses petites organisations ont été mises en faillite en raison de variations de cette idée centrale. Vous ne pouvez vraiment pas prédire qui pourrait trouver une utilisation ou une raison pour pirater votre serveur. C'est précisément en raison de ce type d'hypothèse sous-jacente qu'un gouvernement ou un super pirate pourrait cibler votre système. Ils peuvent ne pas être intéressés par votre application ou vos données, ils peuvent simplement vouloir un point de départ innocent à utiliser dans le cadre d'un hack plus grand ou plus complexe sur une cible plus précieuse.
Serveur Web LAMP normal exécutant une application Web. (Par exemple, AWS EC2 + Apache2 + MySQL + Php7)
Méfiez-vous du "normal". Votre configuration n'est peut-être pas aussi normale que vous le pensez. Cela dépend beaucoup de ce que vous avez installé et de quels référentiels le paquet provient. Certaines des variations à connaître comprennent -
Type de distribution. Par exemple, il existe une grande différence entre les distributions Ubuntu LTS et non LTS. En règle générale, les distributions non LTS auront généralement des mises à jour plus fréquentes et il sera important d'effectuer des mises à jour (ou revoir les mises à jour - voir ci-dessous) plus fréquemment.
Type de référentiel. La plupart des distributions, y compris Ubuntu, ont différents types de référentiels. Il y a les référentiels principaux maintenus par Ubuntu qui passent généralement par des cycles de test assez robustes et qui reçoivent les mises à jour assez rapidement. Ensuite, il existe des référentiels de type "contrib" qui ne sont pas gérés par l'équipe de distribution principale. Il peut s'agir de partenaires tiers ou d'autres utilisateurs ou groupes de développement. L'accent mis sur ces référentiels peut varier considérablement. Parfois, ils se concentreront sur la sécurité et sur la stabilité, d'autres se concentreront sur la stabilité plutôt que sur la sécurité. Il est important de connaître/comprendre les référentiels à partir desquels vous avez installé le logiciel.
Sachez ce qui est installé. Trop souvent, vous entendez parler d'un système qui a été compromis uniquement pour trouver que le compromis s'est produit dans un package ignoré - soit installé par défaut, soit requis par la pile LAMP, mais il s'agit d'une dépendance profondément enfouie ou subtile que vous n'étiez pas conscient de. Assurez-vous d'avoir supprimé tous les packages inutiles (ce qui peut être difficile à déterminer, d'autant plus que certains packages ont des dépendances inhabituelles).
Bibliothèques auxiliaires. Il est courant d'oublier les bibliothèques supplémentaires qui ont été installées, mais qui ne sont pas gérées par l'écosystème apt. Par exemple, une bibliothèque PHP nécessaire pour un usage spécial qui ne faisait pas partie de la charge standard des distributions ou qui devait être construite sur le système en raison d'autres dépendances. Un exemple courant est PHP pilotes de base de données pour les bases de données commerciales. Bien que les choses se soient probablement améliorées depuis la dernière fois que j'ai dû gérer une pile basée sur PHP, je me souviens d'un moment où vous deviez construire le pilote PHP pour Oracle. Bien que le processus soit relativement trivial, vous devez vous rappeler de reconstruire ce pilote après la mise à niveau des bibliothèques dépendantes pour vous assurer que la bibliothèque est liée à la version corrigée. Cela peut également être un problème avec des choses comme openSSL. Une distribution peut installer une version mise à niveau de la bibliothèque partagée, mais vous devrez peut-être prendre des mesures supplémentaires pour vous assurer que votre application utilise réellement la bibliothèque mise à niveau et non l'ancienne bibliothèque avec une vulnérabilité connue.
Vous devez vérifier les mises à jour quotidiennement, puis examiner ces mises à jour pour évaluer leur importance et leur potentiel de rupture de votre système. Bien que le processus de mise à jour d'apt d'Ubuntu soit assez robuste et casse rarement les choses, il arrive de temps en temps. En raison de l'accent mis sur la stabilité, en particulier pour les versions LTS, le processus de mise à jour aura tendance à être conservateur, vous devez donc revoir et pas seulement exécuter la mise à niveau apt-get. Par exemple, en raison de problèmes de dépendance possibles et de la possibilité d'instabilité ou de rupture, vous devrez parfois effectuer une "mise à niveau dist". Ubuntu le fera délibérément pour montrer clairement que vous devez faire attention, c'est-à-dire que la mise à niveau apt-get peut être fiable pour ne pas casser les choses, mais peut ne pas installer tous les correctifs de sécurité. apt-get dist-upgrade travaillera plus dur pour s'assurer que toutes les mises à jour de sécurité sont appliquées, mais peut casser les choses, donc l'administrateur doit faire plus attention.
Ce qui est regrettable, c'est qu'il n'y a pas de véritable raccourci ici. La réalité est que vous êtes dans une situation imparfaite où vous êtes un développeur qui travaille pour une petite entreprise qui ne peut pas se permettre d'employer à la fois un développeur et un administrateur dédié. Vous devez appliquer vos ressources limitées d'une manière qui minimise les risques pour l'entreprise et vous assurer que l'entreprise sait quels sont ces risques et comprendre les probabilités et les conséquences - ils doivent être en position éclairée et savoir qu'ils ont pris la décision en toute connaissance de cause. . J'espère pour le mieux, mais assurez-vous d'avoir prévu le pire. Ayez des sauvegardes fiables et testées. Sachez ce que fera une mise à jour avant d'appliquer la mise à jour. Surveillez les listes de sécurité pour être au courant des menaces nouvelles et émergentes et être en mesure d'évaluer votre exposition et de consulter les journaux pour confirmer vos hypothèses. Vérifiez les mises à jour quotidiennement. Il est tout à fait légitime de décider de ne pas appliquer les mises à jour quotidiennement, mais seulement après avoir évalué ce qu'elles sont et ce qu'elles corrigent et êtes en mesure de prendre la décision en toute connaissance de cause.
En lien avec le point ci-dessus, aucune ingénierie sociale et l'application Web elle-même ne sont sécurisées.
Croire que vous savez et que vous savez peut être un monde à part. J'ai perdu le compte du nombre de fois qu'une évaluation de la sécurité a révélé des vulnérabilités dont je n'étais pas au courant. Il est très probable qu'il existe des vulnérabilités dans PHP (ou toute autre couche impliquée) qui n'ont pas encore été découvertes - ou pire, ont été découvertes par de mauvaises personnes et ne sont pas encore largement connues. Lorsque les professionnels de la sécurité évaluent une application, ils ne déclarent jamais qu'elle est sécurisée. Ils diront qu'aucune vulnérabilité n'a été détectée, mais cela ne signifie pas qu'elle n'existe pas.
C'est certainement une bonne pratique et devrait faire partie de votre routine de sécurité du serveur. Il est difficile de dire si votre plan de sécurité a besoin de plus que cette seule pratique, mais je n'ai jamais vu ni ne peux penser à de bons plans de sécurité qui n'ont pas cela comme fondement.
Ne pas patcher les logiciels et services installés est un risque de sécurité élevé car les bugs et vulnérabilités découverts dans ces packages peuvent souvent entraîner un accès complet à la boîte en exploitant. C'est l'une des premières, sinon la première, chose qu'un attaquant tentera.
Mais les erreurs de configuration du système sont également l'un des principaux moyens utilisés par les attaquants pour compromettre les systèmes. Corriger le logiciel à lui seul ne corrigera pas nécessairement les erreurs de configuration. Parfois, cela se produit, mais ce serait parce que la mauvaise configuration est née de l'installation d'origine de l'application.
Une chose à regarder est de savoir si l'un de vos services s'exécute en tant que root. Il n'y a pas beaucoup de cas où c'est une bonne idée, mais il arrive qu'un service s'exécute en tant que root parce que la personne qui l'a installé ne savait pas mieux ou ne pouvait pas le faire fonctionner en tant que non utilisateur root. Ce n'est qu'un exemple.
Quel que soit le système d'exploitation utilisé, il y aura de bonnes pratiques pour durcir le système d'exploitation. Commencez par là, puis durcissez spécifiquement tous les services/packages installés, tels que MySql, Apache, etc.
Si pendant le déploiement, le système d'exploitation et tous les services ont été spécifiquement effectués conformément aux meilleures pratiques, alors après cela, l'application de correctifs peut être la seule chose que vous devez faire.
Je dis peut-être parce que ce n'est toujours pas une certitude. Cela dépendrait des processus de changement et si les processus couvrent le maintien d'une sécurité adéquate. Les modifications proposées sont-elles examinées pour la sécurité? Les extractions incluent-elles des tests spécifiques à la sécurité? La réponse à ces questions est généralement non et donc des erreurs par un administrateur peuvent se produire et ne pas être détectées.
Fondamentalement, vous ne pouvez pas sécuriser un serveur Web. Il existe des exploits de 0 jour, qui pourraient être corrigés quelques heures après la découverte, mais qui ont déjà été exploités d'ici là. Une bonne société d'hébergement pourrait être en mesure d'agir très rapidement face à de telles menaces. Cependant, un serveur géré coûte cher (en supposant que le personnel de gestion de l'hébergeur vaut quoi que ce soit). Ils pourraient toutefois décider de mettre le serveur hors ligne au cas où ils décideraient que cela est nécessaire pour éliminer une menace actuelle, en donnant la priorité à sécurité, pas disponibilité - ce qui pourrait être faux. sorte de sécurité si vous avez besoin de la boîte et réactif à tout moment. Combien d'argent et combien de vies perdez-vous par heure de panne?
Des fuites de données peuvent également se produire ailleurs. Les sauvegardes sont-elles stockées en toute sécurité? (sécurisé contre l'accès à distance et physique; dans un cas, j'ai pu démontrer l'exfiltration de données non pas à partir du site Web en direct, mais à partir des sauvegardes) Avec quelle facilité une personne peut-elle pénétrer dans la salle des serveurs? Il n'est pas nécessaire qu'un super-criminel comme Lex Luthor vous attaque directement (après tout, il est juste après les 40 gâteaux), mais vous pouvez être un dommage collatéral. Et, oui, j'ai vu des fermes de serveurs secrètes (cas 1: ouvert accidentellement la mauvaise porte, qu'un imbécile avait apparemment oublié de verrouiller et un autre idiot avait décidé d'avoir une poignée de porte à l'extérieur, cas 2: voulait savoir pourquoi il y avait tant de chaleur frigorifique provenant de derrière le panneau de particules, dans une installation de stockage partagée où l'on pouvait espacer au mètre carré). En théorie, exploité par des entreprises professionnelles, dans la pratique ... eh bien. On pourrait saisir l'occasion, soulever quelques serveurs ou lecteurs, les vendre sur eBay et bonne chance par la suite.
Les attaques à distance contre l'infrastructure sont souvent négligées. À proprement parler, cela n'a rien à voir avec le niveau de sécurité du serveur, mais si quelqu'un attaque l'infrastructure de gestion ou le proxy qui sert les packages logiciels pour vos mises à jour apt-get, la sécurité est quand même ... dégradée. Oui, certaines personnes font de telles choses pour le plaisir.
Je suppose que AWS EC2 est raisonnablement sûr en ce qui concerne de tels scénarios, mais AWS EC2 n'est fourni qu'à titre d'exemple, pas comme un fait dans la question du PO (contrairement à l'affirmation selon laquelle l'application Web elle-même est sûre - c'est probablement pour nous empêcher de discuter de toutes nos histoires de guerre sur l'injection SQL et ainsi de suite).