avaliando as preocupações de segurança para executar um servidor de e-mail próprio [fechado]

2

Estou trabalhando em um pequeno centro de pesquisa que precisa gerenciar muitas coisas de forma independente com um orçamento apertado. Uma delas é toda a infraestrutura de TI, incluindo hospedagem na web e e-mail. Embora eu não tenha sido formado como administrador de sistemas, até agora consegui encontrar um servidor-raiz acessível em uma empresa de hospedagem, configurar nossos sites e aplicativos da Web e mantê-los em funcionamento por alguns anos.

Até agora, nosso e-mail foi hospedado externamente, o que significa que pagamos pouco por pouco valor: 875Mb de espaço de armazenamento de e-mail para max. 35 caixas de correio POP. Depois de algumas perdas de dados devido a corrupções na caixa de entrada local em clientes de email, decidi pelo menos investigar a opção de usar o servidor de email postfix / qmail que está presente no servidor raiz que estamos contratando. À primeira vista, há muitas vantagens: poderíamos mudar para contas IMAP virtualmente ilimitadas, incluir o e-mail nas contas de e-mail nos backups do servidor, usar mais armazenamento por caixa de correio, etc. Além disso, o servidor de e-mail já está incluído na taxa que estamos pagando pelo servidor da web, portanto, poderíamos cortar o custo de hospedagem de e-mail externo e até obter muito mais por menos.

A parte técnica tem sido divertida o suficiente: eu tenho sido capaz de configurar tudo (descobrindo as virtudes do painel Plesk) e, em princípio, podemos simplesmente mudar para o novo servidor de e-mail imediatamente. No entanto, não estou confiante de que posso estimar adequadamente os riscos envolvidos no gerenciamento de um servidor de e-mail, em termos de segurança. Claro, eu tenho SpamAssassin e antivírus (Plesk Premium antivírus) habilitado em todas as contas de e-mail, configurei um certificado SSH e adicionei registros SPF, DMARC e DKIM ao nosso DNS. Minha principal preocupação é: isso é suficiente, e quais são as chances de ser atacado e ter todo o servidor comprometido?

Por exemplo, notei como - mesmo nesta fase de testes prematura -, os logs do QMail estão cheios de mensagens como:

Dec 15 17:07:00 server4545 postfix/smtpd[23838]: connect from unknown[91.200.13.5]
Dec 15 17:07:00 server4545 plesk_saslauthd[24512]: Invalid mail address 'albert@'
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: warning: unknown[91.200.13.5]: SASL LOGIN authentication failed: authentication failure
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: lost connection after AUTH from unknown[91.200.13.5]
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: disconnect from unknown[91.200.13.5]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: connect from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: lost connection after CONNECT from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: disconnect from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:20 server4545 postfix/smtpd[23838]: warning: hostname ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.172.216: Name or service not known
Dec 15 17:07:20 server4545 postfix/smtpd[23838]: connect from unknown[118.71.172.216]
Dec 15 17:07:22 server4545 postfix/smtpd[23838]: NOQUEUE: reject: RCPT from unknown[118.71.172.216]: 554 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<[100.74.205.159]>
Dec 15 17:07:22 server4545 postfix/smtpd[23838]: disconnect from unknown[118.71.172.216]
Dec 15 17:07:22 server4545 /usr/lib/plesk-9.0/psa-pc-remote[8577]: Message aborted.
Dec 15 17:07:22 server4545 /usr/lib/plesk-9.0/psa-pc-remote[8577]: Message aborted.

Isso parece sugerir muito interesse de endereços IP totalmente não relacionados, mesmo que eu não esteja usando a coisa para testes. A parte boa parece ser que essas tentativas estão sendo reconhecidas e rejeitadas, mas ainda estou me perguntando de onde elas vêm e o quanto eu deveria me preocupar. Mesmo que eles sejam inocentes, posso imaginar que processar todos esses pedidos poderia causar uma sobrecarga séria para o servidor. Para fins de teste, eu adicionei um registro MX com baixa prioridade em nosso DNS; Gostaria de saber se isso já está "convidando" tantos pedidos para o nosso servidor de e-mail?

Em outras palavras: estou procurando conselhos razoáveis sobre os riscos de segurança envolvidos na execução de um servidor de e-mail. Afinal, se as coisas quebrarem, elas podem quebrar tudo e eu vou ter que lidar com isso sozinho.

Qualquer conselho seria muito apreciado!

Ron

    
por rvdb 15.12.2016 / 20:07

1 resposta

3

Como um ex-administrador que se tornou um testador de penetração, sinto sua dor. No entanto, acontece que, como você parece, eu me importei o suficiente com a segurança do meu sistema para descobrir o que são coisas como DKIM e SPF, e implementá-las, e usar chaves SSH, etc. as coisas certas. Como parece que você é; -)

De seus registros, não parece que você é, mas uma das coisas mais importantes é garantir que você não esteja executando um retransmissor aberto. O link a seguir deve permitir que você teste isso: link

Além disso, você precisa evitar a enumeração do usuário. Você não quer que um invasor consiga se conectar ao seu servidor SMTP e fazer: "VRFY bob" ou "EXPN joe" e fazer com que o servidor de correio responda para informar se o joe existe no sistema ou não. É possível configurar servidores de correio para não suportar esses recursos. Você também não quer que o servidor de email responda a "MAIL TO: tom" para informar imediatamente que o tom existe. Você entendeu a ideia. Analise a enumeração de usuários smtp / pop3 / imap e reduza-a.

Outra coisa - não use pop3 ou imap sem criptografia. A senha passará pela Internet em texto não criptografado - Wifi também é fácil de ser hackeado, e isso dará as credenciais para serviços de e-mail não criptografados em um momento. Você precisa da segurança da camada de transporte (TLS).

Semelhante ao SMTP, você deseja exigir autenticação para usuários remotos que enviam email, mas isso também deve ser enviado por uma conexão TLS. Além disso, não se esqueça de exigir autenticação para usuários locais que enviam e-mails e impedir a retransmissão aberta internamente. Eu fiz recentemente um teste de caneta em um escritório de advocacia onde eu podia fazer telnet para o servidor de e-mail na porta 25 e enviar um e-mail do chefe da empresa para um funcionário, dizendo que ele tinha um aumento ou demitido. Obviamente eu também não fiz, mas você não quer permitir essa possibilidade. É melhor não ter repúdio, se possível.

Como está claro que você é bom em descobrir coisas para si mesmo, eu não vou entrar em grandes detalhes, mas basta dizer - você precisa saber sobre os méritos relativos de coisas como POP3S e POP3 com STARTTLS, a diferença entre as portas 25, 465, 587, etc. IMAP e IMAPS, etc. A exigência de certificados TLS para autenticação provavelmente está bem acima da média, mas não use certificados TLS de servidor auto-assinados, você deve obter os documentos de boa fé. Você pode obtê-los barato de ir-papai ou similar. Não use SSL2, SSL3 ou TLSv1.0. O TLSv1.2 deve ser tudo o que estiver ativado, se possível.

Além disso, configure seus servidores de e-mail para não anunciar a versão do software (ou qualquer detalhe do produto, se possível) ao se conectar à porta. Um banner genérico simples deve ser suficiente.

Exigir senhas strongs dos seus usuários e administradores!

Mais uma coisa: para evitar spam, a listagem cinza pode funcionar muito bem se configurada corretamente. Eu usei por um longo tempo e nunca tive problemas com o correio não entregue.

Máquinas na internet estão sempre sendo digitalizadas e cutucadas. Se você o configurou com segurança, então eu não me preocuparia muito com isso (embora você possa usar a limitação de taxa do iptables se estiver preocupado com DoS - ou falar com seu ISP), MAS no PLESK, etc. SSH, use o iptables para colocar na lista de permissões os IPs que REQUEREM acesso a essas portas, para que os invasores não possam nem mesmo ver que estão lá. Use o nmap no seu servidor para ver o que os invasores verão. Se todas as portas aparecem filtradas para o público em geral, exceto suas portas de e-mail, então ótimo. Use apenas HTTPS, não HTTP para se conectar ao material de administração da web e novamente, apenas TLSv1.2. Ou, melhor ainda, obtenha apenas para escutar localhost, de modo que fique inacessível de fora e, em seguida, use o encaminhamento de porta SSH para se conectar a ele!

O Google para "PRODUCTNAME que protege o servidor" para cada item de software que você está usando, e também "teste de invasão do PRODUCTNAME", "Explorações do PRODUCTNAME" pode ajudar.

Muito importante - Mantenha todo o software e o sistema operacional Linux atualizados e atualizados.

Um risco muitas vezes negligenciado é o risco de comprometer sua própria estação de trabalho. Como administrador, você é o principal alvo. Se isso acontecer, um invasor poderá roubar suas senhas ou chaves SSH e encontrar seus arquivos que informarão tudo o que precisam saber sobre sua configuração. Depois que eles tiverem isso, eles poderão entrar no seu sistema de e-mail, independentemente de quão bem você o tenha protegido, mesmo que seja uma solução hospedada do Office 365. De fato, de certa forma, será mais fácil para eles se ele estiver hospedado em outro lugar e uma configuração mais familiar.

Não faça login em sua máquina como root ou administrador, a menos que seja necessário. Não dê mais acesso aos seus colegas do que eles precisam. etc. Tenha muito cuidado ao abrir anexos de e-mail, etc. - as coisas de sempre.

    
por 15.12.2016 / 20:36