Impedindo que outros aplicativos se liguem às portas 80 e 443

16

Na semana passada, recebi uma ligação de um cliente assustado porque ele pensava que seu site estava hackeado. Quando procurei no site dele, vi a apache2página padrão. Naquela noite, meu servidor ( Ubuntu 16.04 LTS) havia atualizado e reiniciado. Normalmente, quando algo dá errado, eu seria alertado durante a noite. Desta vez não, porque o sistema de monitoramento verifica o código de status HTTP 200 e a apache2página padrão vem com o código de status 200.

O que aconteceu é que, durante a inicialização, apache2foi mais rápido ligar as portas 80 e 443 do que o meu servidor web nginx real. Eu não instalei o apache2 sozinho. Através aptitude why apache2eu descobri o pacote php7.0 exige.

Simplesmente remover apache2não funcionará porque aparentemente o php7.0 exige. De alguma forma, é possível criar uma restrição para que apenas o nginx possa se conectar às portas 80 e 443?

Outras soluções também são bem-vindas.

— Boyd
fonte

15

E é por isso que você deve configurar seus servidores ativos para atualizar somente quando solicitar explicitamente uma atualização, para que você possa primeiro testar suas atualizações em uma máquina de desenvolvimento.

— Nzall #

2

Não testo as atualizações em uma máquina de teste primeiro, mas sempre verifique os registros de alterações antes de agendar manualmente a atualização. Também parece que o apache2 escapou durante uma atualização anterior. Só que desta vez ele reiniciou o apache2 foi o primeiro a se conectar às portas http e https.

— Boyd

9

Como uma nota lateral - This time not, because the monitoring system checks for HTTP status code 200. Você pode melhorar o sistema de monitoramento, verificando o conteúdo real da página da web (alguma sequência específica no corpo ou no cabeçalho); isso será mais confiável.

— VL-80

2

@Boyd Não testo primeiro as atualizações em uma máquina de teste, mas sempre verifique os registros de alterações. Mas você acabou de experimentar o quão pouco confiável é esse método. A leitura de um changelog não pode lhe dizer qual será o impacto em um sistema implantado, nem sobre erros ou incompatibilidades introduzidas.

— Andrew Henle

5

@Nzall para ser justo, parece que esse tipo de problema pode não ter aparecido em uma máquina de teste ... ele efetivamente tem uma condição de corrida para saber se o apache2 ou o nginx ligará as portas, e a máquina de teste poderia, teoricamente, ter nginx win (por acaso) durante a duração do teste, para que o problema não seja descoberto.

— Doktor J

29

Você não pode impedir que uma porta seja vinculada pelo serviço errado. No seu caso, basta remover o apache do início automático e você deve ser bom.

Para 16.04 e mais recentes:

sudo systemctl disable apache2

Para versões mais antigas do Ubuntu:

sudo update-rc.d apache2 disable

— Gerald Schneider
fonte

2

Eu farei isso, mas esperava poder me defender de situações futuras nas quais outro pacote que se vincula às portas 80 e 443 esteja instalado no meu sistema sem saber como uma dependência de outro pacote.

— Boyd

1

Como este é 16.04, também:systemctl disable apache2

— muru 13/04

12

@Boyd: Por que você está instalando cegamente os pacotes "sem saber"? Como, em seu servidor ativo usado pelos clientes, você nem está lendo quais pacotes e dependências estão sendo instalados? E como você não está testando tudo em um servidor espelho antes de executar? Estes são princípios básicos de operações e resolverão todos os seus problemas.

— Lightness Races com Monica

6

@BoundaryImposition Desejar me defender contra a vinculação de software às portas não significa que estou instalando pacotes cegamente. Mas também somos pessoas, erros são cometidos. Infelizmente, não podemos testar todas as operações em um servidor fictício primeiro, mas, neste caso, ele não mostraria o problema imediatamente, porque o apache2 foi instalado uma semana antes do aparecimento do problema (o sistema foi reiniciado nesse meio tempo sem problemas) ) Embora não possamos testar todas as atualizações, ainda atualizamos semanalmente. Preferimos patches de segurança atualizados sobre o risco de tempo de inatividade limitado (através do monitoramento).

— Boyd

3

@Boyd: "Infelizmente não podemos testar todas as operações em um servidor fictício primeiro" Por que não? Seus clientes sabem que você pula este procedimento?

— Lightness Races com Monica

27

Se você realmente não está usando apache2, e é o PHP 7.0 que está exigindo, parece que você libapache2-mod-php7.0instalou. Esse pacote é inútil sem o Apache. Como você está usando o nginx, provavelmente também possui php7.0-fpmou php7.0-cgiinstalou, o que é suficiente para atender php7.0aos requisitos de dependência:

$ 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>

Se você tiver um dos php7.0-{fpm,cgi}instalados, poderá prosseguir e desinstalar o Apache.

— muru
fonte

6

Hoje eu realmente aprendi que, na minha situação, estou melhor apenas instalando php7.0-fpme não o php7.0pacote. Isso também é recomendado por Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/…

— Boyd

5

Esta é a solução real para o problema real: Como instalar o nginx e PHP no Ubuntu sem instalar o Apache.

— 21817 David Cullen #

2

Para responder sua pergunta, você provavelmente pode restringir uma porta a um aplicativo específico usando o SElinux. Eu não o usei e tenho apenas um conhecimento superficial de suas capacidades, mas aqui está um ponteiro que encontrei neste site:

/server//a/257056/392230

Nessa resposta, o wzzrd parece mostrar como conceder a um aplicativo específico (foo) permissão para ligar a uma porta específica (803). Você só precisa ter a configuração da política para que somente seu aplicativo (nginx) tenha permissão para as portas que você especificar (80 e 443).

Baseando-me na resposta do wzzrd, pode ser tão simples quanto adicionar isso à política

allow nginx_t nginx_port_t:tcp_socket name_bind;

e executando isso

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

No entanto, imagino que você também precisará de uma linha na política que especifique que nenhum outro programa possa se vincular a essas portas.

No final, estou apenas adivinhando qual é a configuração apropriada.

De qualquer forma, não acho que tenha havido um Ubuntu que tenha o SElinux instalado e ativado por padrão. Como acredito que exija a aplicação de certos patches em vários utilitários e uma opção de kernel, pode ser mais fácil usar o Centos, que possui o SElinux instalado e ativado desde o início.

Desculpe, não sou de mais ajuda. Talvez em outra ocasião, baixe uma imagem do Centos e tente isso; será um bom passo para o aprendizado. Atualizarei esta resposta se o fizer.

— JoL
fonte

2

lol @ "pode ser mais fácil simplesmente usar Centos"

— David Cullen

2

Algo que ainda não vi nas respostas, mas ainda é uma possibilidade:

Mude a configuração do Apache para ouvir outra porta, apenas por precaução. Você pode fazer isso abrindo o arquivo de configuração do Apache e alterando as linhas que têm Listen 80para outra porta.

— Milan Drossaerts
fonte

Isso "resolve" o problema da mesma forma que a resposta aceita, mas com a questão adicional de ter que explicar / documentar sua alteração. Além disso, embora ele resolva um problema, nenhum deles resolve o problema inteiro. Se o apache estiver desativado, mas da próxima vez que reiniciar, o aplicativo X for vinculado à porta 80, você terá a mesma falha novamente.

— Darren H

0

Não tenho uma resposta para sua pergunta exata, mas talvez você precise analisar sua distribuição. Eu consideraria qualquer distro que permite que os serviços (apache2 aqui) na instalação sejam inseguros. Considere procurar uma distro que não faça isso. Não posso dizer que já vi esse comportamento no Archlinux, tenho certeza que existem outros.

— phelbore
fonte

1

Então, o que você recomenda, formatar o servidor e instalar outra distribuição? E por que você acredita que o ubuntu não é capaz de lidar com serviços específicos, como alguma outra resposta indicada? Esta resposta é um comentário religioso e não ajuda em nada.

— Wtower

Eu não formataria o servidor agora e instalaria uma nova distribuição, mas certamente mudaria na próxima vez que tivesse que atualizar servidores. O Ubuntu acabou de ser mostrado neste post como inadequado, pois está habilitando serviços que não foram configurados (exceções a isso seria algo como um login gráfico ou serviço de som, coisas que normalmente simplesmente funcionam e não estão expostas à Internet pública ) Eu temia que a resposta pudesse parecer um pouco religiosa, mas essa não era a intenção, estava tentando apontar uma solução para o que eu considerava o maior problema.

— Phelbore

1

Embora eu concorde com você que é uma distribuição imprópria fazer isso, acho que isso seria mais apropriado como um comentário, pois realmente não responde à pergunta.

— JOL

É um ponto justo.

— Lightness Races com Monica