Ainda existe uma razão pela qual a ligação à porta

Question

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

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 para 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.
Isso éreservado pela IANA,

As portas bem conhecidas são aquelas de 0 a 1023.

As portas bem conhecidas do DCCP NÃO DEVEM ser usadas sem o registro da IANA. O procedimento de registro é definido em [RFC4340], Seção 19.9.

Para opiniões divergentes, verifique,

1. A partir de umtópico de perguntas sobre linux(leia no link para mais contexto)

   O limite da porta 1024 realmente morde o rabo. Ele força uma prática de daemon que pode abrir brechas de segurança que tornam o limite ineficaz como medida de segurança.

   • OAs 20 principais vulnerabilidades do SANSnotas

     Vários dos principais serviços do sistema fornecem interfaces remotas para componentes do cliente por meio de chamadas de procedimento remoto (RPC). Eles são expostos principalmente por meio de endpoints de pipe nomeados acessíveis por meio do protocolo Common Internet File System (CIFS), portas TCP/UDP bem conhecidas e, em certos casos, portas TCP/UDP efêmeras. Historicamente, existiram muitas vulnerabilidades em serviços que podem ser exploradas por usuários anônimos. Quando exploradas, essas vulnerabilidades proporcionam ao invasor os mesmos privilégios que o serviço tinha no host.

---

Hoje em dia, protocolos comoBitTorrenteSkypepassaram por portas efêmeras para o espaço não reservado e não se preocupam com acesso root. O alvo énão apenas contornando essa antiga segurança de porta reservada; Os protocolos de hoje queremignorar até mesmo o perímetro da rede(Skype é um bom exemplo disso). As coisas irão mais longe à medida que a largura de banda e a disponibilidade da rede aumentarem, quando todos os usuários de computador provavelmenteexecutar um servidor web por conta própria-- etalvez,sem saber, serparte de um rede de bots.

---

Precisamos da segurança desejada por esses métodos antigos,
mas isso precisará ser feito com métodos mais novos agora.

Answer 2

Bem, o pensamento original, pelo que me lembro dos dias do BSD Unix, era que se esperava que portas <1024 fossem reservadas para "serviços bem conhecidos", e a suposição ainda era que os servidores seriam relativamente raros e que pessoas com privilégios de root ser considerado "confiável" de alguma forma. Então você tinha que ter privilégios para vincular um soquete para escutar em uma porta que representaria um serviço de rede que outros usuários acessariam.

As portas 1024-4999 deveriam ser 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 foram jogadas pela janela muito rapidamente. Verifique a lista de reserva de números de porta TCP da IANA para ver o quão alto as coisas subiram.

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 seria iniciado 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 prosseguiriam a partir daí. Não consigo me lembrar quais mecanismos de segurança existiam para proteger serviços RPC conhecidos contra falsificação de identidade.

Não tenho certeza se há um bom motivo hoje em dia para tudo isso, mas como a maioria do mundo *nix, as coisas tendem a se acumular em vez de 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 mais camadas de código do passado antigo, com o tempo ainda sendo representado pelo número de segundos desde alguma data antiga (01/01/1970). para ser exato). Ele provavelmente não está longe.

Answer 3

Antigamente, os usuários regulares costumavam fazer 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.

Hoje em dia, o uso típico é que apenas o administrador e algumas outras pessoas confiáveis ​​tenham logins em um servidor, portanto, se o modelo for refeito hoje, a restrição <1024 poderá não estar presente.

Answer 4

Faz sentido que os serviços que aceitam senhas do sistema sejam executados em portas privilegiadas; isso significa que os usuários com contas shell não podem configurar serviços "falsos" na mesma porta para capturar 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 conseguisse configurar um daemon ssh não autorizado, ele poderia capturar as senhas de outros usuários e obter acesso às suas contas (é claro que eles teriam que fazer isso enquanto o o daemon ssh legítimo estava inativo, talvez para manutenção ou durante a inicialização ou desligamento do sistema)

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