Empêcher d'autres applications de se lier aux ports 80 et 443

16

La semaine dernière, j'ai reçu un appel d'un client effrayé parce qu'il pensait que son site Web avait été piraté. Lorsque j'ai recherché son site Web, j'ai vu la apache2page par défaut. Cette nuit-là, 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 la apache2page par défaut est fournie avec le code d'état 200.

Ce qui s'est passé, c'est qu'au démarrage, il apache2était plus rapide de se connecter aux ports 80 et 443 que mon serveur Web réel nginx. Je n'ai pas installé apache2 moi-même. A travers aptitude why apache2j'ai découvert le paquet php7.0 exige.

La simple suppression apache2ne fonctionnera pas car apparemment php7.0 l'exige. Est-il possible de créer une restriction afin que seul nginx soit autorisé à se lier aux ports 80 et 443?

D'autres solutions sont également les bienvenues.

linux apache-2.2 ubuntu nginx port Boyd
la source
15
Et c'est pourquoi vous devez configurer vos serveurs en direct pour qu'ils ne se mettent à jour que lorsque vous demandez explicitement une mise à jour, afin de pouvoir d'abord tester vos mises à jour sur une machine de développement.
Nzall
2
Je ne teste pas d'abord les mises à niveau sur une machine de test, mais vérifie toujours les journaux des modifications avant de planifier manuellement la mise à niveau. Il semble également qu'apache2 se soit 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 du
9
En note - This time not, because the monitoring system checks for HTTP status code 200. Vous pouvez améliorer le système de surveillance en le faisant vérifier le contenu réel de la page Web (une chaîne particulière dans le corps ou l'en-tête), ce sera plus fiable.
VL-80
2
@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 n'est pas 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 qui sont introduits.
Andrew Henle
5
@Nzall pour être honnête, il semble que ce genre de problème ne se soit pas présenté sur une machine de test ... il a effectivement une condition de concurrence quant à savoir si apache2 ou nginx liera les ports, et la machine de test pourrait théoriquement finir par avoir nginx gagne (juste par hasard) pendant la durée du test afin que le problème ne soit pas découvert.
Doktor J

Réponses:

29

Vous ne pouvez pas empêcher un port d'être lié par le mauvais service. Dans votre cas, supprimez simplement apache du démarrage automatique 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
Gerald Schneider
la source
2
Je vais le faire, mais j'espérais pouvoir me défendre contre des situations futures dans lesquelles un autre package qui se lie aux ports 80 et 443 est installé sans le savoir sur mon système en tant que dépendance d'un autre package.
Boyd
1
Puisque c'est 16.04, aussi:systemctl disable apache2
muru le
12
@Boyd: Pourquoi installez-vous aveuglément des packages "à votre insu"? Comment se fait-il que, sur votre serveur en direct utilisé par les clients, vous ne lisez même pas quels packages et dépendances sont installés? Et comment se fait-il que vous ne testiez pas tout sur un serveur miroir avant de l'exécuter? Ce sont des principes de fonctionnement de base qui résoudront tous vos problèmes.
Courses de légèreté avec Monica
6
@BoundaryImposition Vouloir se défendre contre la liaison de logiciels aux ports ne signifie pas que j'installe simplement des packages à l'aveugle. Mais nous sommes aussi des gens, des erreurs sont commises. Malheureusement, nous ne pouvons pas d'abord tester chaque opération sur un serveur factice, mais dans ce cas, il n'aurait pas immédiatement montré le problème, car apache2 a été installé une semaine avant l'apparition du problème (le système a même été redémarré entre-temps sans aucun problème). ). Bien que nous ne puissions pas tester chaque mise à niveau, nous effectuons une mise à niveau hebdomadaire. Nous préférons les correctifs de sécurité à jour au risque de temps d'arrêt limité (grâce à la surveillance).
Boyd
3
@Boyd: "Malheureusement, nous ne pouvons pas d'abord tester toutes les opérations sur un serveur factice" Pourquoi pas? Vos clients savent-ils que vous ignorez cette procédure?
Courses de légèreté avec Monica
27

Si vous n'utilisez vraiment pas apache2et que c'est PHP 7.0 qui en a besoin, il semble que vous l'ayez libapache2-mod-php7.0installé. Ce paquet est inutile sans Apache. Puisque vous utilisez nginx, vous avez probablement également installé php7.0-fpmou php7.0-cgiinstallé, ce qui est suffisant pour satisfaire php7.0les exigences 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 php7.0-{fpm,cgi}installé l'un ou l'autre, vous pouvez continuer et désinstaller Apache.

muru
la source
6
J'ai en effet appris aujourd'hui que dans ma situation, je préfère simplement installer php7.0-fpmet non le php7.0package. Ceci est également conseillé par Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/…
Boyd
5
C'est la vraie solution au vrai problème: Comment installer nginx et PHP sur Ubuntu sans installer Apache.
David Cullen
2

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

/server//a/257056/392230

Dans cette réponse, wzzrd semble montrer comment donner à une application spécifique (foo) l'autorisation de se lier à un port spécifique (803). Il vous suffirait d'avoir la configuration de la politique pour que seule votre application (nginx) soit autorisée sur les ports que vous spécifiez (80 et 443).

En me basant sur la réponse de wzzrd, cela pourrait être aussi simple que d'ajouter cela à 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 politique 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 un Ubuntu sur lequel SElinux est installé et activé par défaut. Parce que je pense que cela nécessite d'appliquer certains correctifs à divers utilitaires et une option de noyau, il pourrait être plus facile d'utiliser simplement Centos qui a SElinux installé et activé dès le départ.

Désolé, je ne suis d'aucune aide. Peut-être une autre fois, je vais télécharger une image de Centos et essayer ceci; ce sera une bonne étape d'apprentissage. Je mettrai à jour cette réponse si je le fais.

JoL
la source
2
lol @ "il pourrait être plus simple d'utiliser simplement Centos"
David Cullen
2

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

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

Milan Drossaerts
la source
Cela "résout" le problème tout comme la réponse acceptée, mais avec le problème supplémentaire de devoir expliquer / documenter votre changement. De plus, même si cela résout un problème, aucun ne résout le problème dans son intégralité. Si apache est désactivé mais la prochaine fois qu'il redémarre, l'application X se lie au port 80, vous avez à nouveau le même défaut.
Darren H
0

Je n'ai pas de réponse à votre question exacte, mais peut-être que vous avez besoin de regarder votre distribution. Je considérerais que toute distribution qui permet aux services (apache2 ici) lors de l'installation n'est pas sécurisée. Envisagez d'examiner une distribution qui ne fait pas cela. 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.

phelbore
la source
1
Alors, que recommandez-vous pour formater le serveur et installer une autre distribution? Et pourquoi pensez-vous qu'ubuntu n'est pas en mesure de gérer des services spécifiques, comme une autre réponse l'a indiqué? Cette réponse est un commentaire religieux et n'est d'aucune utilité.
Wtower
Je ne formaterais pas le serveur pour l'instant et n'installerais pas une nouvelle distribution, mais je changerais certainement la prochaine fois que je devrais mettre à niveau les serveurs. Ubuntu vient d'être montré dans cet article comme étant inadapté car il permet des services qui n'ont pas été configurés (des exceptions à cela seraient quelque chose comme 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 ne paraisse un peu religieuse, 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
1
Bien que je convienne avec vous qu'il est inapproprié d'une distribution de le faire, je pense que cela aurait été plus approprié en tant que commentaire, car cela ne répond pas vraiment à la question.
JoL
C'est un bon point.
Courses de légèreté avec Monica