Por que é recomendado executar o Postfix em uma prisão chroot?

Como um invasor pode conceder acesso ao sistema de arquivos quando apenas 25 e 587 portas estão disponíveis externamente? Como isso é possível através do protocolo SMTP? Possui vulnerabilidades?

Um protocolo geralmente não funciona, mas certas implementações podem; especificamente, o conjunto Sendmail SMTP ¹ (que costumava ser a principal implementação de SMTP do Unix por um tempo) tinha algumas falhas de segurança, algumas delas exemplos muito famosos .

Na verdade, acho que a maior parte do design do Postfix – tanto o uso de chroots quanto a arquitetura multiprocessos com forte separação entre tarefas – veio diretamente como uma resposta aos problemas de segurança que o Sendmail costumava ter. (Sendmail costumava ser executado como root!)

¹ Não deve ser confundido com o programa 'sendmail' em seu /usr/lib, que de fato era o Sendmail naquela época, mas o que está em seu sistema ainda é Postfix e apenas segue a interface do Sendmail original.

Por que o Postfix é altamente recomendado para instalação em um chroot, mas o Dovecot que publica portas POP3/IMAP e armazena e-mails no sistema de arquivos não é?

Dovecot usa chroot . Sua arquitetura (assim como a do Postfix, na verdade) permite que isso seja feito de uma maneira mais refinada, de modo que, por exemplo, os processos de "login" altamente expostos possam fazer isso automaticamente, tornando-se um pouco menos importante fazer o mesmo em todo o serviço. Mas o POP/IMAP também o torna um pouco mais complexo que o SMTP, pois precisa acessar caixas de correio armazenadas nos diretórios iniciais dos usuários (que era o layout tradicional), portanto, um único chroot não funcionaria para esse tipo de configuração.

Na verdade, é recomendado executar tudona prisão)) Pelo menos tudo o que está ouvindo na Internet. Por outro lado, "um sistema 100% seguro é 100% inútil" )) A segurança é sempre uma espécie de compensação. Eu suponho que o protocolo Postfix (SMTP) não é mais seguro que POP ou IMAP, apenas menos empresas preocupadas com segurança expõem portas POP/IMAP fora da rede corporativa, enquanto o SMTP é exposto com muito mais frequência. A exploração bem conhecida em portas expostas é a "injeção de código" - enviar a carga com um pedaço de texto que de alguma forma pode ser interpretado pelo programa de escuta como código executável. Como exatamente essas explorações são construídas e enviadas está muito além desta discussão)) Minha opinião pessoal, de que outra implementação do SMTP - sendmail - tem um código mais sensível à segurança do que o postfix, pode ser religiosa))

1. Através de vulnerabilidades ainda desconhecidas . Não deveria ser possível, mas merdas acontecem, bibliotecas backdoor sorrateiras são incluídas até mesmo nas ferramentas mais importantes, pessoas cometem erros de programação e assim por diante. O Postfix é frequentemente elogiado por seu estilo de código muito limpo , mas usa outras bibliotecas de software que não são tão boas .

2. Tecnicamente você não pode instalá-lo totalmente em chroot. O Postfix consiste em muitos serviços interdependentes, alguns dos quais se beneficiam do chroot, outros não podem ser executados em um chroot. Por exemplo, um serviço proxymap é projetado especificamente para fornecer a outros serviços chroot um acesso controlado a itens fora do chroot e, portanto, ele próprio não deve ser chroot. Se o serviço Postfix é executado em um chroot ou não, é definido por meio do sinalizador correspondente em um master.cfarquivo (aquele na 5ª coluna). Provavelmente, os autores do Dovecot acham que não precisa de tal proteção.

3. O Postfix é executado sob a supervisão de seu próprio masterprocesso, configurado usando master.cf. Ele não foi projetado para ser executado de outra forma, incluindo a prisão ProtectSystem do systemd. O principal suporte ao desenvolvedor do Postfix é fornecido por meio de sua lista de discussão de "usuários"; eles não irão apoiá-lo se você o executar em tal prisão.