Ainda existe uma razão pela qual a ligação à porta 1024 só é autorizada para raiz em sistemas Unix?

Question

Em sistemas Unix, ligação à porta tcp < 1024 de um processo sem privilégios de root é negado.

Qual foi o motivo inicial e ainda é válido?

Por exemplo, o servidor http não precisa de privilégios de root para servir a página html.

Qual processo / protocolo um usuário do Unix precisa ter certeza de que ele é executado com privilégios de root?

Obrigado

    

Answer 1

Esse intervalo de portas não deve ser definido pelo programador.
É reservado pela IANA

The Well Known Ports are those from 0 through 1023.

DCCP Well Known ports SHOULD NOT be used without IANA registration. The registration procedure is defined in [RFC4340], Section 19.9.

Para ver opiniões diferentes,

1. De um tópico do linuxquestions (leia o link para mais contexto)

   The port 1024 limit actually bites itself in the tail. It forces a daemon practice that might open security holes which make the limit ineffective as a security measure.

   • As principais vulnerabilidades do SANS Top-20

     Several of the core system services provide remote interfaces to client components through Remote Procedure Calls (RPC). They are mostly exposed through named pipe endpoints accessible through the Common Internet File System (CIFS) protocol, well known TCP/UDP ports and in certain cases ephemeral TCP/UDP ports. Historically, there have been many vulnerabilities in services that can be exploited by anonymous users. When exploited, these vulnerabilities afford the attacker the same privileges that the service had on the host.

Atualmente, protocolos como BitTorrent e Skype passou por portas efémeras para o espaço não reservado e não se preocupou com o acesso root. O alvo é não apenas ignorando essa antiga segurança de porta reservada ; Os protocolos de hoje querem contornar até mesmo o perímetro da rede (o Skype é um bom exemplo disso). As coisas vão além, à medida que a largura de banda e a disponibilidade da rede aumentam quando cada usuário de computador provavelmente irá executar um servidor web fora de si mesmo - e maybe , sem saber , seja parte de um botnet .

Precisamos da segurança desejada por esses métodos antigos
mas precisará ser feito com novas formas agora.

    

Answer 2

Bem, o pensamento original, como eu me lembro dos dias do BSD Unix, era que os ports < Esperava-se que 1024 fossem reservados para "serviços bem conhecidos", e a suposição ainda era de que servidores seriam relativamente raros e que pessoas com privilégios de root seriam presumivelmente "confiáveis" de alguma forma. Então você tinha que ter o privilégio de ligar um soquete para escutar em uma porta que representasse um serviço de rede que outros usuários acessariam.

As portas 1024-4999 foram planejadas para serem usadas como portas "efêmeras" que representariam o lado do cliente de uma conexão TCP. As portas 5000+ foram destinadas a servidores não raiz.

Obviamente, todas essas suposições saíram pela janela rapidamente. Verifique a lista de reserva do número de porta TCP da IANA para ver o quanto as coisas ficaram altas.

Uma solução para este problema foi a ideia do portmapper RPC. Em vez de reservar uma porta TCP para cada serviço, o serviço iniciaria em uma porta aleatória e informaria ao daemon do portmapper onde estava escutando. Os clientes perguntariam ao portmapper "onde está o serviço X" ouvindo e procedendo de lá. Não consigo me lembrar de quais mecanismos de segurança foram instalados para proteger os serviços de RPC conhecidos da falsificação de identidade.

Não tenho certeza se existe uma Boa Razão nos dias de hoje por tudo isso, mas como a maioria das coisas do mundo nix tendem a se acumular versus serem completamente reinventadas.

Alguém leu Vernor Vinge? Lembro-me dele escrevendo em um de seus romances sobre um sistema de computador em um futuro distante que incorporava camadas e camadas de código do passado antigo, com o tempo ainda sendo representado pelo número de segundos desde alguma data antiga (1/1/1970). para ser exato). Ele provavelmente não está longe.

    

Answer 3

Antigamente, os usuários comuns costumavam fazer o login em máquinas Unix. Então você não gostaria que um usuário comum configurasse um serviço ftp falso ou algo assim.

Atualmente, o uso típico é que apenas o administrador e algumas outras pessoas de confiança fazem logins em um servidor, portanto, se o modelo foi refeito hoje, o < 1024 restrição pode não estar presente.

    

Answer 4

Esta é uma convenção histórica.

Há muito tempo atrás, o número de sistemas era muito menor. Também não havia DNS, os sites de FTP pediam sua senha anônima para ser seu endereço de e-mail e não havia spam.

Era essencialmente um "acordo de cavalheiros" implícito. Os sistemas eram bem administrados, se alguém estragasse tudo isso, você sabia com quem falar ou, se eles eram petulantes, ser expulso da rede significava ficar offline.

Hoje, com o TCP / IP em tudo, isso não oferece mais segurança.

    

Answer 5

Faz sentido para os serviços que aceitam senhas do sistema serem executadas em portas privilegiadas; Isso significa que os usuários com contas de shell não podem configurar serviços "falsos" na mesma porta para capturar os detalhes de login das pessoas ou negar acesso configurando serviços não funcionais nas mesmas portas.

Se você tivesse uma caixa multiusuário, e um usuário sem privilégios pudesse configurar um daemon falso, eles poderiam capturar as senhas de outros usuários e obter acesso a suas contas (é claro que eles teriam que fazer enquanto o daemon ssh legítimo estava desativado, talvez para manutenção ou durante a inicialização ou desligamento do sistema)

Coisas que não aceitam senhas de sistema não importam muito, embora existam grandes problemas de segurança em compartilhar coisas como servidores da web entre usuários em uma caixa multiusuário (como descobriram provedores de hospedagem compartilhada)