Evitar que otras aplicaciones se vinculen al puerto 80 y 443

16

La semana pasada recibí una llamada de un cliente asustado porque pensó que su sitio web fue pirateado. Cuando busqué en su sitio web, vi la apache2página predeterminada. Esa noche mi servidor ( Ubuntu 16.04 LTS) se actualizó y reinició. Normalmente, cuando algo sale mal, me habrían alertado durante la noche. Esta vez no, porque el sistema de monitoreo verifica el código de estado HTTP 200, y la apache2página predeterminada viene con el código de estado 200.

Lo que sucedió es que durante el inicio apache2fue más rápido enlazar a los puertos 80 y 443 que mi servidor web actual nginx. No instalé apache2 yo mismo. A través aptitude why apache2descubrí que el paquete php7.0 lo requiere.

Simplemente eliminar apache2no funcionará porque aparentemente php7.0 lo requiere. ¿De alguna manera es posible crear una restricción para que solo nginx pueda unirse al puerto 80 y 443?

Otras soluciones son más que bienvenidas también.

Boyd
fuente
15
Y es por eso que debe configurar sus servidores en vivo para que solo se actualicen cuando solicite explícitamente una actualización, para que primero pueda probar sus actualizaciones en una máquina de desarrollo.
Nzall
2
No pruebo primero las actualizaciones en una máquina de prueba, pero siempre verifico los registros de cambios antes de programar manualmente la actualización. También parece que apache2 se deslizó durante una actualización anterior. Es solo que esta vez reinició apache2 fue el primero en unirse a los puertos http y https.
Boyd el
99
Como nota al margen - This time not, because the monitoring system checks for HTTP status code 200. Puede mejorar el sistema de monitoreo haciendo que verifique el contenido real de la página web (alguna cadena particular en el cuerpo o encabezado), esto será más confiable.
VL-80
2
@Boyd No pruebo primero las actualizaciones en una máquina de prueba, pero siempre verifico los registros de cambios. Pero acabas de experimentar lo poco confiable que es ese método. Leer un registro de cambios no puede decirle cuál será el impacto en un sistema implementado, ni le informará sobre errores o incompatibilidades que se introducen.
Andrew Henle
55
@Nzall para ser justos, parece que este tipo de problema podría no haber aparecido en una máquina de prueba ... efectivamente tiene una condición de carrera en cuanto a si apache2 o nginx unirán los puertos, y la máquina de prueba en teoría podría terminar teniendo nginx gana (solo por casualidad) durante la duración de las pruebas para que no se descubra el problema.
Doktor J

Respuestas:

29

No puede evitar que un puerto esté vinculado por el servicio incorrecto. En su caso, simplemente elimine apache del inicio automático y debería ser bueno.

Para 16.04 y más reciente:

sudo systemctl disable apache2

Para versiones anteriores de Ubuntu:

sudo update-rc.d apache2 disable
Gerald Schneider
fuente
2
Haré esto, pero esperaba poder defenderme de situaciones futuras en las que otro paquete que se une al puerto 80 y 443 se instala sin saberlo en mi sistema como una dependencia de otro paquete.
Boyd el
1
Dado que esto es 16.04, también:systemctl disable apache2
muru
12
@Boyd: ¿Por qué estás instalando ciegamente paquetes "sin saberlo"? ¿Cómo es que, en su servidor en vivo utilizado por los clientes, ni siquiera está leyendo qué paquetes y dependencias se están instalando? ¿Y por qué no estás probando todo en un servidor espejo antes de ejecutarlo? Estos son principios básicos de operaciones y resolverán todos sus problemas.
Lightness compite con Monica el
66
@BoundaryImposition Querer defender contra el enlace de software a los puertos no significa que solo esté instalando paquetes a ciegas. Pero también somos personas, se cometen errores. Desafortunadamente, no podemos probar primero todas las operaciones en un servidor ficticio, pero en este caso no habría mostrado inmediatamente el problema, porque apache2 se instaló una semana antes de que apareciera el problema (el sistema incluso se reinició mientras tanto sin ningún problema) ) Si bien no podemos probar todas las actualizaciones, seguimos actualizando semanalmente. Preferimos parches de seguridad actualizados sobre el riesgo de tiempo de inactividad limitado (a través de la supervisión).
Boyd el
3
@Boyd: "Desafortunadamente, no podemos probar todas las operaciones en un servidor ficticio primero" ¿Por qué no? ¿Sus clientes saben que omite este procedimiento?
Lightness compite con Monica el
27

Si realmente no está utilizando apache2, y es PHP 7.0 el que lo requiere, entonces parece que lo ha libapache2-mod-php7.0instalado. Ese paquete es inútil sin Apache. Como está utilizando nginx, es probable que también tenga php7.0-fpmo esté php7.0-cgiinstalado, cualquiera de los cuales es suficiente para satisfacer php7.0los requisitos de dependencia:

$ 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 tiene alguno de los dos php7.0-{fpm,cgi}instalados, puede continuar y desinstalar Apache.

muru
fuente
66
De hecho, aprendí hoy que en mi situación estoy mejor con solo instalar php7.0-fpmy no el php7.0paquete. Esto también lo aconseja Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/…
Boyd el
55
Esta es la solución real al problema real: cómo instalar nginx y PHP en Ubuntu sin instalar Apache.
David Cullen
2

Para responder a su pregunta, probablemente pueda restringir un puerto a una aplicación específica utilizando SElinux. No lo he usado yo mismo y solo tengo un conocimiento superficial de sus capacidades, pero aquí hay un puntero que encontré en este sitio:

/server//a/257056/392230

En esa respuesta, wzzrd parece mostrar cómo otorgar a una aplicación específica (foo) permiso para vincularse a un puerto específico (803). Simplemente tendría que tener la configuración de la política para que solo su aplicación (nginx) tenga permitido los puertos que especifique (80 y 443).

Basándome en la respuesta de wzzrd, podría ser tan simple como agregar esto a la política

allow nginx_t nginx_port_t:tcp_socket name_bind;

y corriendo esto

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

Sin embargo, imagino que también necesitará una línea en la política que especifique que ningún otro programa puede vincularse a esos puertos.

Al final, solo adivino cuál es la configuración adecuada.

De todos modos, no creo que haya habido un Ubuntu que tenga SElinux instalado y habilitado por defecto. Debido a que creo que requiere la aplicación de ciertos parches a varias utilidades y una opción de kernel, podría ser más fácil simplemente usar Centos, que tiene SElinux instalado y habilitado desde el primer momento.

Lo siento, no soy de más ayuda. Tal vez en otro momento, descargaré una imagen de Centos y probaré esto; Será un buen paso de aprendizaje. Actualizaré esta respuesta si lo hago.

JoL
fuente
2
lol @ "podría ser más fácil simplemente usar Centos"
David Cullen
2

Algo que aún no he visto en las respuestas, pero aún es una posibilidad:

Cambie la configuración de Apache para escuchar otro puerto, por si acaso. Puede hacerlo abriendo el archivo de configuración de Apache y cambiando las líneas que tienen Listen 80a otro puerto.

Milan Drossaerts
fuente
Eso "resuelve" el problema igual que la respuesta aceptada, pero con el problema adicional de tener que explicar / documentar su cambio. Además, aunque resuelve un problema, ninguno resuelve todo el problema. Si apache está deshabilitado pero la próxima vez que se reinicia, la aplicación X se une al puerto 80, vuelve a tener el mismo error.
Darren H
0

No tengo una respuesta a tu pregunta exacta, pero tal vez necesites mirar tu distribución. Consideraría que cualquier distribución que permita servicios (apache2 aquí) en la instalación es insegura. Considera buscar una distribución que no haga eso. No puedo decir que haya visto ese comportamiento en Archlinux, estoy seguro de que hay otros.

Phelbore
fuente
1
Entonces, ¿qué me recomiendan para formatear el servidor e instalar alguna otra distribución? ¿Y por qué crees que ubuntu no puede manejar servicios específicos, como lo indica alguna otra respuesta? Esta respuesta es un comentario religioso y no es útil en absoluto.
Wtower
No formatearía el servidor en este momento e instalaría una nueva distribución, pero ciertamente cambiaría la próxima vez que tuviera que actualizar servidores. En esta publicación, se acaba de mostrar que Ubuntu no es adecuado ya que habilita servicios que no se han configurado (las excepciones a esto serían algo así como un inicio de sesión gráfico o un servicio de sonido, cosas que normalmente solo funcionan y no están expuestas a Internet público ) Temía que la respuesta saliera un poco religiosa, pero esa no era la intención, estaba tratando de señalar una solución a lo que vi como el problema más grande.
phelbore
1
Aunque estoy de acuerdo con usted en que es impropio de una distribución hacer eso, creo que esto habría sido más apropiado como comentario, ya que en realidad no responde a la pregunta.
JoL
Es un punto justo.
Lightness compite con Monica el