Question Empêcher d'autres applications de se lier au port 80 et 443


La semaine dernière, un client effrayé m'a appelé parce qu'il pensait que son site Web avait été piraté. Lorsque j'ai consulté son site Web, j'ai vu le apache2 page par défaut. Cette nuit mon serveur (Ubuntu 16.04 LTS) avait mis à niveau et redémarré. Normalement, quand quelque chose se passe mal, j'aurais été alerté pendant la nuit. Cette fois non, car le système de surveillance vérifie le code d’état HTTP 200 et que le apache2 La page par défaut est fournie avec le code d’état 200.

Qu'est-ce qui est arrivé est que lors du démarrage apache2 était plus rapide pour se connecter aux ports 80 et 443 que mon serveur Web actuel nginx. Je n'ai pas installé apache2 moi-même. À travers aptitude why apache2 J'ai découvert que le paquet php7.0 le requiert.

Enlever simplement apache2 ne fonctionnera pas car apparemment php7.0 le requiert. Est-il possible en quelque sorte de créer une restriction afin que seul nginx soit autorisé à se connecter au port 80 et 443?

D'autres solutions sont également les bienvenues.


15
2018-04-13 07:33


origine


C'est pourquoi vous devez configurer vos serveurs Live pour qu'ils ne se mettent à jour que lorsque vous demandez explicitement une mise à jour. Vous pouvez donc d'abord tester vos mises à jour sur une machine de développement. - Nzall
Je ne teste pas d'abord les mises à niveau sur une machine de test, mais je vérifie toujours les journaux des modifications avant manuellement planification de la mise à niveau. De plus, il semblerait qu'apache2 ait glissé lors d'une mise à niveau antérieure. C'est juste que cette fois, il a redémarré apache2 a été le premier à se lier aux ports http et https. - Boyd
En note de côté - This time not, because the monitoring system checks for HTTP status code 200. Vous pouvez améliorer le système de surveillance en vérifiant le contenu réel de la page Web (une chaîne particulière dans le corps ou l'en-tête), ce qui sera plus fiable. - VL-80
@Boyd Je ne teste pas d'abord les mises à niveau sur une machine de test, mais je vérifie toujours les journaux des modifications. Mais vous venez de constater à quel point cette méthode est peu fiable. La lecture d'un journal des modifications ne peut pas vous dire quel sera l'impact sur un système déployé, ni vous informer des bogues ou des incompatibilités introduites. - Andrew Henle
@Nzall pour être juste, il semblerait que ce type de problème ne se soit peut-être pas présenté sur une machine de test ... il a en réalité une situation critique, à savoir si apache2 ou nginx lieront les ports, et la machine de test pourrait théoriquement finir par avoir nginx gagne (juste par hasard) pour la durée des tests afin que le problème ne soit pas découvert. - Doktor J


Réponses:


Vous ne pouvez pas empêcher un port d'être lié par le mauvais service. Dans votre cas, il suffit de supprimer Apache de Autostart et vous devriez être bon.

Pour 16.04 et plus récent:

sudo systemctl disable apache2

Pour les anciennes versions d'Ubuntu:

sudo update-rc.d apache2 disable

29
2018-04-13 07:35



Je le ferai, mais j'espérais pouvoir me défendre contre les situations futures dans lesquelles un autre package lié au port 80 et 443 est installé sans le savoir sur mon système en tant que dépendance d'un autre package. - Boyd
Puisqu'il s'agit de 16.04, aussi: systemctl disable apache2 - muru
@Boyd: Pourquoi installez-vous aveuglément des paquets "sans le savoir"? Comment se fait-il que sur votre serveur actif utilisé par les clients, vous ne lisiez même pas quels paquets et dépendances étaient installés? Et pourquoi ne pas tout tester sur un serveur miroir avant de l'exécuter? Ceux-ci sont principes de fonctionnement de base et va résoudre tous vos problèmes. - Lightness Races in Orbit
@BoundaryImposition Vouloir se défendre contre une liaison logicielle aux ports ne signifie pas que je vais installer aveuglément des paquets. Mais nous sommes aussi des gens, des erreurs sont commises. Malheureusement, nous ne sommes pas en mesure de commencer par tester toutes les opérations sur un serveur factice, mais dans ce cas, le problème n'aurait pas été immédiatement détecté, car apache2 avait été installé une semaine avant l'apparition du problème (le système a même été redémarré sans aucun problème). ). Bien que nous ne soyons pas en mesure de tester chaque mise à niveau, nous effectuons néanmoins une mise à niveau hebdomadaire. Nous préférons les correctifs de sécurité à jour au risque limité d'indisponibilité (grâce à la surveillance). - Boyd
@Boyd: "Malheureusement, nous ne pouvons pas d'abord tester toutes les opérations sur un serveur factice" Pourquoi pas? Vos clients sont-ils au courant que vous ignorez cette procédure? - Lightness Races in Orbit


Si vous n'utilisez pas vraiment apache2, et c'est PHP 7.0 qui l'exige, alors on dirait que vous avez libapache2-mod-php7.0 installée. Ce paquet est inutile sans Apache. Puisque vous utilisez nginx, vous avez probablement aussi php7.0-fpm ou php7.0-cgi installés, dont chacun suffit à satisfaire php7.0Conditions de dépendance de:

$ apt-cache depends php7.0
php7.0
 |Depends: php7.0-fpm
 |Depends: libapache2-mod-php7.0
  Depends: php7.0-cgi
  Depends: php7.0-common
  Conflicts: <php5>

Si vous avez l'un des php7.0-{fpm,cgi} installé, vous pouvez continuer et désinstaller Apache.


27
2018-04-13 09:31



J’ai en effet appris aujourd’hui que, dans ma situation, je ferais mieux de simplement installer php7.0-fpm et pas le php7.0 paquet. Ceci est également conseillé par Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/… - Boyd
Voici la vraie solution au vrai problème: Comment installer nginx et PHP sur Ubuntu sans installer Apache. - David Cullen


Pour répondre à votre question, vous pouvez probablement limiter un port à une application spécifique en utilisant SElinux. Je ne l'ai pas utilisé moi-même et je n'ai qu'une connaissance superficielle de ses capacités, mais voici un pointeur que j'ai trouvé sur ce site:

https://serverfault.com/a/257056/392230

Dans cette réponse, wzzrd semble montrer comment donner à une application spécifique (foo) le droit de se lier à un port spécifique (803). La politique doit être configurée pour que seule votre application (nginx) soit autorisée à utiliser les ports spécifiés (80 et 443).

En me basant sur la réponse de wzzrd, cela pourrait être aussi simple que de l'ajouter à la politique

allow nginx_t nginx_port_t:tcp_socket name_bind;

et en cours d'exécution

semanage port -a -t nginx_port_t -p tcp 80
semanage port -a -t nginx_port_t -p tcp 443

Cependant, j'imagine que vous aurez également besoin d'une ligne dans la stratégie qui spécifie qu'aucun autre programme ne peut se lier à ces ports.

En fin de compte, je devine simplement quelle est la configuration appropriée.

Quoi qu'il en soit, je ne pense pas qu'il y ait eu une Ubuntu sur laquelle SElinux a été installé et activé par défaut. Comme je pense que cela nécessite l’application de certains correctifs à divers utilitaires et à une option du noyau, il serait peut-être plus simple d’utiliser Centos sur lequel SElinux est installé et activé dès le départ.

Désolé, je ne vous aide pas davantage. Peut-être qu'une autre fois, je téléchargerai une image de Centos et l'essayerai; ce sera une bonne étape d'apprentissage. Je mettrai à jour cette réponse si je le fais.


2
2018-04-14 03:23



lol @ "il serait peut-être plus facile d'utiliser simplement Centos" - David Cullen


Quelque chose que je n'ai pas encore vu dans les réponses, mais qui reste une possibilité:

Changez la configuration Apache pour écouter un autre port, au cas où. Vous pouvez le faire en ouvrant le fichier de configuration Apache et en modifiant les lignes qui ont Listen 80 vers un autre port.


2
2018-04-14 07:51



Cela "résout" le problème de la même manière que la réponse acceptée, mais avec le problème supplémentaire de devoir ensuite expliquer / documenter votre modification. En outre, même si cela résout un problème, ni l'un ni l'autre ne résout le problème dans son ensemble. Si apache est désactivé mais qu'il redémarre au prochain démarrage, l'application X se lie au port 80, vous avez à nouveau le même défaut. - Darren H


Je n'ai pas de réponse à votre question exacte, mais vous devez peut-être regarder votre distribution. Je considérerais toute distribution qui permet aux services (apache2 ici) lors de l’installation de ne pas être sécurisés. Pensez à rechercher une distribution qui ne le fait pas. Je ne peux pas dire que j'ai jamais vu ce comportement sur Archlinux, je suis sûr qu'il y en a d'autres.


0
2018-04-14 00:57



Alors, que recommandez-vous pour formater le serveur et installer une autre distribution? Et pourquoi croyez-vous que Ubuntu n’est pas en mesure de gérer des services spécifiques, comme l’a indiqué une autre réponse? Cette réponse est un commentaire religieux et pas utile du tout. - Wtower
Je ne voudrais pas formater le serveur pour l'instant et installer une nouvelle distribution, mais je changerais certainement la prochaine fois que je devrais mettre à niveau des serveurs. Ubuntu vient d’être montré que cet article ne convenait pas, car il permet d’activer des services qui n’ont pas été configurés (par exemple, une connexion graphique ou un service audio, des choses qui fonctionnent normalement et ne sont pas exposées à l’Internet public. ). J'avais peur que la réponse vienne d'un peu religieux, mais ce n'était pas l'intention, c'était d'essayer de trouver une solution à ce que je considérais comme le problème le plus important. - phelbore
Bien que je convienne avec vous qu'il est inapproprié d'une distribution de faire cela, je pense que cela aurait été plus approprié comme commentaire, car cela ne répond pas vraiment à la question. - JoL
C'est un point juste. - Lightness Races in Orbit