Evitar que outros aplicativos sejam vinculados às portas 80 e 443

15

Na semana passada recebi uma ligação de um cliente assustado porque ele achava que o site dele havia sido hackeado. Quando pesquisei o site dele, vi a página padrão apache2 . Naquela noite, meu servidor ( Ubuntu 16.04 LTS ) tinha atualizado e reinicializado. Normalmente, quando algo dá errado, eu teria sido alertado durante a noite. Desta vez, não, porque o sistema de monitoramento verifica o código de status HTTP 200, e a página padrão apache2 vem com o código de status 200.

O que aconteceu é que, durante a inicialização, apache2 foi mais rápido para ligar às portas 80 e 443 do que o meu servidor nginx real. Eu não instalei o apache2 sozinho. Através de aptitude why apache2 eu descobri que o pacote php7.0 requer isso.

A simples remoção de apache2 não funcionará porque aparentemente o php7.0 exige isso. É de alguma forma possível criar uma restrição para que apenas o nginx tenha permissão para ligar à porta 80 e 443?

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

    
por Boyd 13.04.2017 / 09:33

5 respostas

29

Você não pode impedir que uma porta seja vinculada pelo serviço errado. No seu caso, basta remover o apache do autostart e você deve estar bem.

Para 16.04 e mais recente:

sudo systemctl disable apache2

Para versões antigas do Ubuntu:

sudo update-rc.d apache2 disable
    
por 13.04.2017 / 09:35
27

Se você realmente não está usando apache2 , e é o PHP 7.0 que requer isso, então parece que você tem libapache2-mod-php7.0 instalado. Esse pacote é inútil sem o Apache. Como você está usando o nginx, é provável que você também tenha php7.0-fpm ou php7.0-cgi instalado, um dos quais é suficiente para satisfazer os requisitos de dependência de php7.0 :

$ 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} instalado, você pode ir em frente e desinstalar o Apache.

    
por 13.04.2017 / 11:31
2

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

link

Nessa resposta, o wzzrd parece mostrar como conceder permissão a uma aplicação específica (foo) para ligar a uma porta específica (803). Você teria que ter a configuração da política de modo que somente o seu aplicativo (nginx) tenha permissão para as portas especificadas (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 pode ser vinculado a essas portas.

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

Enfim, não acho que tenha havido um Ubuntu que tenha o SElinux instalado e habilitado por padrão. Porque eu acredito que requer a aplicação de certos patches para vários utilitários e uma opção de kernel, pode ser mais fácil simplesmente usar o Centos que tem o SElinux instalado e ativado desde o início.

Desculpe, não tenho mais ajuda. Talvez outra hora, eu baixarei uma imagem de Centos e tentarei isto; será um bom passo de aprendizado. Eu atualizarei esta resposta se eu fizer isso.

    
por 14.04.2017 / 05:23
2

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

Altere a configuração do Apache para ouvir outra porta, apenas no caso. Você pode fazer isso abrindo o arquivo de configuração do Apache e alterando as linhas que possuem Listen 80 para outra porta.

    
por 14.04.2017 / 09:51
0

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

    
por 14.04.2017 / 02:57