Por que as portas abaixo de 1024 são privilegiadas?

Ouvi dizer que é um recurso de segurança, mas muitas vezes parece um problema de segurança. Se eu quiser escrever um servidor que use uma porta privilegiada, não apenas tenho que me preocupar com a segurança do meu código, mas tenho que me preocupar especialmente se estou usando o setuid correto e descartando privilégios.

Verdade. Mas isso também significa que qualquer pessoa que fale com você sabe que você deve ter privilégios de root para executar esse servidor. Quando você faz login em um servidor na porta 22 (digamos), sabe que está falando com um processo que foi executado pelo root (problemas de segurança à parte), então você confia nele com sua senha para esse sistema ou outras informações que você possa não confiar em ninguém com uma conta de usuário nesse sistema.

Referência: http://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html .

Edite para elaborar o raciocínio: muitos dos serviços de rede mais importantes – telnet (sim, ainda é usado – surpreendentemente frequentemente), SSH, muitos serviços HTTP, FTP etc. etc. – envolvem o envio de dados importantes como senhas pela rede. Em uma configuração segura, algum tipo de criptografia, seja inerente ao protocolo (SSH) ou envolvida (stunnel, IPSec), protege os dados de serem rastreados na conexão, mas todas essas proteções terminam no servidor.

Para proteger seus dados adequadamente, você precisa ter certeza de que está falando com o servidor ‘real’. Hoje, os certificados seguros são a maneira mais importante de fazer isso na Web (e em outros lugares): você assume que apenas o servidor ‘real’ tem access ao certificado, portanto, se você verificar se o servidor com o qual está falando tem esse certificado vou confiar.

As portas privilegiadas funcionam de maneira muito semelhante: somente o root tem access a portas privilegiadas, portanto, se você estiver falando com uma porta privilegiada, sabe que está falando com o root. Isso não é muito útil na web moderna: o que importa é a identidade do servidor, não o seu IP. Em outros tipos de redes, esse não é o caso: em uma rede acadêmica, por exemplo, os servidores geralmente são controlados fisicamente por equipes confiáveis ​​em salas seguras, mas os alunos e a equipe têm access bastante livre aos usuários. Nesta situação, muitas vezes é seguro assumir que você sempre pode confiar em root, para que você possa efetuar login e enviar dados privados para uma porta privilegiada com segurança. Se usuários comuns pudessem ouvir em todas as portas, você precisaria de uma camada extra para verificar se um determinado programa era confiável com determinados dados.

Você não diz qual plataforma você está usando, mas pelo menos no Linux você pode usar resources (especificamente CAP_NET_BIND_SERVICE) para permitir que um processo não-raiz escute em uma porta menor que 1024. Veja, por exemplo, Existe uma maneira de processos não-raiz para ligar a portas “privilegiadas” no Linux?

Outra alternativa é configurar as regras do iptables para encaminhar o tráfego da porta privilegiada para a porta sem privilégios (usei isso na produção e é bastante simples e funciona bem). Também é descrito no link acima.