Por que o sudo é requerido para inicializar um servidor web em um dado ip: port?

Question

Estou configurando um servidor web baseado em Python na minha caixa Debian.

Configuração:

• O sistema operacional Debian é baseado em VM, mas eu mudei o VirtualBox de NAT para Bridged.
• IP da configuração da VM = 192.168.1.7 (por tela de administração do meu roteador ou ifconfig ).
• Configurei com êxito o encaminhamento de porta do meu roteador para ssh e HTTP.
• Configurei com sucesso o DNS dinâmico do meu roteador usando o dyndns.com.

Independentemente do servidor web específico do Python que estou usando (Django, CherryPy, biblioteca padrão), eu tenho que iniciar o servidor web @ 192.168.1.7:80 usando sudo . Caso contrário, recebo um erro sobre não ter permissão para acessar a porta. Nenhum dos tutoriais do servidor menciona a necessidade de usar sudo ao especificar um ip: port.

Pergunta: por que preciso usar o sudo para iniciar esses servidores da web? É uma indicação de que eu não deveria estar usando 192.168.1.7 ? Ou que eu não estou definindo um arquivo de configuração corretamente em algum lugar?

    

Answer 1

Somente processos com permissões de root podem escutar em portas privilegiadas. Esta é uma convenção de segurança padrão do Unix.

    

Answer 2

É um comportamento padrão que usuários sem privilégios não podem se vincular a portas com privilégios (números de porta abaixo de 1024). Portanto, uma aplicação que gostaria de ligar à porta 80, por exemplo, terá que executar privilégios (geralmente isso significa executar como root) para ligar a essa porta.

Uma abordagem comum é executar um pequeno processo de "ouvinte" com um usuário privilegiado que aceita a conexão e, em seguida, gera um processo sem privilégios para manipular a solicitação. Eliminar privilégios para o processamento de pedidos é feito por motivos de segurança. Se alguém é capaz de explorar o processo que lida com o pedido, então normalmente ele permite que um intruso execute comandos usando os mesmos privilégios que o processo de processamento. Portanto, seria ruim lidar com toda a solicitação usando um processo privilegiado.

No entanto, para muitas aplicações, é comum atualmente rodar como não-root; mas tais processos, é claro, não podem se ligar a portas privilegiadas, em seguida, na configuração padrão. Portanto, servidores como o Tomcat ou o JBoss costumavam se ligar a portas altas como 8080 para não precisarem de um ouvinte privilegiado.

É claro que, se você expor esse processo à Internet, provavelmente fornecerá acesso à porta 80, já que cada navegador tentará primeiro se conectar à porta 80 quando o protocolo HTTP for usado. W trabalho comum para fornecer isso é usar um firewall ou porta-tradutor entre o aplicativo e a Internet pública. Assim, as solicitações atingem o firewall solicitando a porta 80, mas o firewall encaminha a solicitação para algum host interno na porta 8080. Dessa forma, o servidor da web real pode operar em portas altas enquanto está disponível publicamente na porta 80.

- (internet request) ----> (port 80)[Firewall] ------> (port 8080)[Webserver]

Às vezes, esse redirecionamento é feito simplesmente usando a regra iptables NAT:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Isso permite executar um aplicativo sem privilégios ouvindo na porta 8080, enquanto todas as solicitações de entrada para a porta 80 são redirecionadas para a porta 8080.

No entanto, usando os kernels modernos do Linux, existe outra possibilidade: Usar recursos.

setcap CAP_NET_BIND_SERVICE=+ep /some/webserver/binary

Isso permitiria que binary se associasse a portas privilegiadas, mesmo quando iniciado a partir de um usuário não raiz. Veja man capabilities para mais detalhes.