Trabalho elaborado por: Ricardo Nuno Mendão da Silva Jorge Miguel Morgado Henriques

Transcrição

1 Trabalho elaborado por: Ricardo Nuno Mendão da Silva Jorge Miguel Morgado Henriques

2 Contents 1. Introdução Objectivos Passos necessários à activação dos serviços Alterações de ficheiros Ficheiro m Ficheiro mc Ficheiro sasl2/sendmail.conf Ficheiro access Ficheiro aliases Ficheiro dovecot.conf Testes Serviço POP e IMAP com SSL Relaying de mensagens a clientes locais Relaying de mensagens a clientes externos Encapsulamento do endereço de origem Redireccionamento de correio com destino ao exterior Comando VRFY e EXPN Utilizadores não suportados Dúvidas e funcionalidades não cumpridas Conclusão Bibliografia... 23

3 1. Introdução Desde os primórdios da Internet que um dos principais serviços, senão o principal, é o serviço de correio electrónico. É um serviço que para o seu funcionamento completo utiliza dois protocolos distintos, um para enviar s e outro para os receber. O protocolo para enviar denomina-se de SMTP Simple Mail Transport Protocol e é definido pelo RFC 821 [IETF82], o que pelo baixo número do RFC indica que é um protocolo bastante antigo. O SMTP é totalmente baseado em texto e utiliza a porta 25 para efectuar a comunicação. Em 1995 surgiu o ESMTP Extended SMTP [wikipedia06], cuja novidade foi o comando EHLO que mostrava ao utilizador as extensões que aquele servidor suportava, sendo esta versão definida pelo RFC Mais tarde, em 2001, restituiu-se para o RFC 2821 [IETF01], onde todo o protocolo encontra-se definido na totalidade, juntando os dados dos dois últim os RFC s.u m a evolução do SMTP foi o uso de meios de autenticação, normalmente através de um username e password, contudo como este protocolo é baseado em texto, grandes problemas de segurança advêm, levanto a que surgisse a extensão STARTTLS, que permite efectuar ligações entre cliente-servidor utilizando um canal seguro. Para implementar o protocolo SMTP, surgiram desde logo, os denominados M TA s Mail Transport Agents [jgranjal,psimoes0607], sendo o Sendmail um dos primeiros. Para implementar a segunda funcionalidade do serviço de correio electrónico, nomeadamente a recepção de , surgiram principalmente dois protocolos, o POP3 Post Office Protocol e o IMAP Internet Message Access Protocol. O funcionamento do POP3, baseia-se em permitir o cliente efectuar a ligação ao servidor de , realizar o download das mensagens para o seu computador local, apagar os s da sua conta no servidor e desligar-se do mesmo. O IMAP por sua é desenhado para permitir contas com mais de um cliente, ou seja, o cliente apenas acede ao servidor, consulta os s, mas só voluntariamente os remove do servidor. O IMAP em relação ao POP3 tem certas vantagens, como por exemplo [wikipedia06a]: Permitir que vários clientes se liguem simultaneamente à mesma caixa, É mais rápido em casos onde os utilizadores têm muitos s ou s muito grandes, visto o IMAP4 manter a ligação activa durante toda a sessão, ao contrário do POP3 que só está ligado em quanto efectua o dow nload de novos m ail s. Neste relatório vai-se apresentar todo o processo efectuado para implementar um servidor de correio electrónico, utilizando o Sendmail [sendmail06] para implementar o serviço de envio, através do protocolo SMTP e o Dovecot [dovecot06] para implementar o serviço de recepção através de POP3 e IMAP. A recepção de requer obrigatoriamente que ocorra autenticação, assim como o envio para utilizadores localizados fora da rede local. Para tal o sistema de autenticação utilizado será o SASL Simples Authentication and Security Layer, que permite utilizar um tipo de autenticação por este suportado, num protocolo que tenha sido instalado com SASL [IETF97].

4 2. Objectivos Os objectivos deste trabalho passam por implementar um servidor de correio electrónico que suporte os serviços POP3 e IMAP apenas com suporte SSL e o serviço SMTP com e sem SSL através do Sendmail. O servidor SMTP deverá: Responder por dois domínios, gsr05.dei.uc.pt e pcg5105.dei.uc.pt. Permitir o relaying de mensagens a utilizadores locais, sem autenticação. Autorizar relaying de mensagens a clientes provenientes de endereços externos, utilizando TLS/SSL e autenticação. Alterar em todas as mensagens enviadas o endereço de origem para gsr05.dei.uc.pt. Reencaminhar todo o tráfego com destino ao exterior para o servidor principal smtp.dei.uc.pt. Não disponibilizar os comandos VRFY e EXPN, por questões de segurança. Suportar uma lista de utilizadores locais que não têm permissões para receber correio. 3. Passos necessários à activação dos serviços. Para iniciar todos os serviços requeridos, foram necessários alguns passos. Passos para a configuração directa do Sendmail: Configuração de um a macro no ficheiro pcg5105.mc. Geração do ficheiro pcg5105.cf através da macro configurada no ponto anterior, utilizando o comando m4. Copiar o ficheiro pcg5105.cf para o ficheiro Sendmail.cf. Passos para a configuração dos ficheiros adjacentes ao Sendmail: Adicionar ao ficheiro /etc/mail/access as regras para filtrar o relaying ou o acesso ao servidor. Construir o access.db através do comando makemap. Adicionar ao ficheiro /etc/mail/local_host_names, os domínios pelos quais o servidor deverá responder. Adicionar ao ficheiro /etc/aliases algum grupo e respectivos utilizadores necessários, correndo o newaliases para actualizar o aliases.db. Passos para a configuração do saslauthd:

5 Adicionar ao ficheiro /usr/lib/sasl2/sendmail.conf o mecanismo utilizado para autenticação. Passos para a configuração do dovecot: Definir no ficheiro dovecot.conf os protocolos a aceitar, neste caso apenas o imaps e o pop3s. Por fim, arrancar com: Service sendmail start Service saslauthd start Service dovecot start 4. Alterações de ficheiros Neste ponto irão-se descrever as alterações efectuadas aos ficheiros do sistema, para o bom funcionamento do serviço de correio electrónico e para uma boa implementação de todas as funcionalidades e limitações requeridas pelos objectivos deste trabalho Ficheiro m4 Criou-se o ficheiro dei.uc.pt.m 4 com base no ficheiro generic.m4, alterando apenas o id, tal como se pode observar na figura Ficheiro mc Figura 1 ficheiro. m4 utilizado. O ficheiro. Mc foi criado também a partir de um ficheiro genérico, mas desta vez específico para o sistema operativo linux, sendo que foi o ficheiro que mais alterações sofreu, permitindo implementar todas as funcionalidades requeridas. Na figura que se segue pode-se observar o ficheiro em questão.

6 Figura 2 Ficheiro pcg5105.dei.uc.pt Ao observar o ficheiro representado em cima, destaca-se em primeiro lugar o DOMAIN (dei.uc.pt), sendo o comando que indica qual o ficheiro m4 a utilizador no momento em que for efectuado o m ake das m acros.de seguida dentro do rectângulo verde, encontra-se o comando que define o SMART_HOST, ou seja, o servidor principal utilizado para relaying de mensagens, cujo destino é no exterior, implementando assim a funcionalidade de encaminhar todas as mensagens com destino ao exterior para o servidor principal. Dentro do próximo rectângulo, a castanho, encontram-se os três comandos que permitem m ascarar todos os endereços de origem, dentro do domínio dei.uc.pt, para gsr05.dei.uc.pt. O comando MASQUERADE_AS indica a mascara, o comando MASQUERADE_DOMAIN indica o domínio a ser mascarado e a FEATURE(masquerade_entire_domain) indica que todos os subdominios serão mascarados.

7 De seguida, vêm dois dos comandos mais importantes, os comandos que permitem algum controlo sobre o acesso ao servidor. O prim eiro, FEATU RE(access.db), indica ao Sendm ail para utilizar o ficheiro access.db para obter informação sobre as permissões de acesso e relaying. O segundo é uma FEATURE(blacklist_recipients), que permite introduzir no ficheiro access.db filtros que proíbam a utilização do servidor por utilizadores locais. Mais abaixo, encontra-se o comando que não permite ao utilizador utilizar os comandos VRFY e EXPN,nom eadam ente o com ando define(confprivacy_flag S,goaw ay). A próxima secção permite implementar a extensão de autenticação, utilizando o mecanismo LOGIN e PLAIN e para implementar este serviço seguramente, foi necessário definir os certificados e chaves para o uso do STARTTLS, apresentado na última secção assinalada Ficheiro sasl2/sendmail.conf Neste ficheiro configurou-se o necessário para o sistema de autenticação saslauth utilizador o modo PLAIN, por forma a no momento da autenticação do cliente, o sistema utilizar os dados das contas de utilizadores contidas no servidor, consultando mais precisamente o ficheiro /etc/passwd. De seguida pode-se observar a alteração efectuada no ficheiro Sendmail.conf. Figura 3 ficheiro Sendmail.conf Como se pode observar, apenas foi adicionada a linha a informar qual o mecanismo de autenticação,nom eadam ente m ech_list:lo G IN PLAIN Ficheiro access O ficheiro access, foi modificado por forma a permitir o relaying sem autenticação de servidores locais e a excluir os utilizadores contidos no grupo badusers, dando razão à existência da FEATURE(blacklist_recipients) contida no ficheiro pcg5105.mc, apresentado no ponto Na figura que se segue pode-se observar o ficheiro criado. Figura 4 ficheiro access

8 Na figura 4 pode-se observar, sublinhado a azul, o comando que permite o relaying de mensagens para utilizadores da rede local, estando incluida a rede do LGSR e a rede do Vmware utilizada para testes. A vermelho encontra-se o comando que nega aos utilizadores que pertencem ao grupo criado, badusers, a utilização deste servidor para o envio e recepção de mensagens Ficheiro aliases No ficheiro aliases apenas foi adicionado o grupo badusers, com um utilizador para teste, nomeadamente o utilizador user1, como se pode observar na figura 5, criando assim uma mailling list manual. O objectivo desta mailling list é servir de exemplo para a proibição de acesso ao serviço por parte de utilizadores locais, neste caso de um grupo. Figura 5 Excerto do ficheiro /etc/access. Para actualizar o ficheiro access.db bastou correr o comando newaliases após efectuar a alteração no ficheiro apresentado. Na secção de testes vai ser apresentado o resultado desta alteração Ficheiro dovecot.conf N o ficheiro dovecot.conf,apenas se alterou o cam po protocols,deixando apenas as opções imaps e pop3s, permitindo assim apenas o acesso ao mail sobre estes dois protocolos de segurança.

9 5. Testes Para efectuar todo o cenário de testes, foi utilizado um servidor a correr na plataforma linux com a distribuição Fedora Core 6 e dois clientes, um também em linux e um outro em windows através da aplicação Microsoft Outlook De notar que a rede local utilizada foi a rede Para simular uma rede externa foi utilizada a rede Serviço POP e IMAP com SSL Para cenário de teste do IMAP com SSL, utilizou-se uma conta criada no Outlook 2007 para o utilizador rnsilva@gsr05.dei.uc.pt. Utiliza-se neste caso não o ip do laboratório GSR, mas um outro ip local, visto esta simulação estar actualmente a correr em Vmware, contudo o processo não varia em nada. Figura 7 Conta criada no Outlook 2007 Na figura 7, observa-se os dados da conta criada, sendo que o interessante neste ponto é basicam ente o ip do Incom m ing m ailserver, o Incom ing server(im AP) no porto 993,o uso de SSL e os dados de autenticação previamente inseridos. Ao tentar consultar o , é perguntado ao cliente se este aceita o certificado do servidor visto não ser de uma CA conhecida, tal como se pode observar na figura 8.

10 Figura 8 Aviso de Certificado. Figura 9 Detalhes do certificado. Na figura 9 pode-se observar os detalhes do certificado utilizado, sendo que neste cenário foi utilizado um certificado criado posteriormente num trabalho de outra cadeira. Ao aceitar o certificado, o utilizador consegue verificar os s que o servidor tem na sua conta. Não lhe foi apresentada uma janela a pedir o nome de utilizador e a password pois esses dados já estavam definidos na conta, com o dem onstra a figura 7, na secção Logon Inform ation. De seguida pode-se observar a caixa de correio do utilizador, com uma nova mensagem por ler.

11 Ao observar-se as propriedades da mensagem obtém-se o seguinte: Figura 10 Caixa de mail do utilizador rnsilva. Figura 11 propriedades da mensagem recebida. Pode-se observar o nom e do servidor de em ail,nom eadam ente gsr05.dei.uc.pt e o tipo de encriptação utilizada, entre outros dados menos importantes neste caso. Para o caso de ligação com POP3s, criou-se também no Outlook uma outra conta, desta feita com POP3 em vez de IMAP, como se pode observar na figura seguinte.

12 Figura 12 Conta de cliente com POP3. Ao efectuar o teste de ligação, aparece a janela para introdução dos dados de autenticação. Figura 13 Teste de ligação.

13 Ao inserir a password correcta o cliente vai observar o sucesso do teste, como comprovado na figura em baixo representada. Figura 14 ligação com sucesso. Do lado do servidor, fica o seguinte registo no maillog. Figura 15 maillog. Pode-se observar logo pela primeira linha, assinalada a vermelho, o acesso via pop3 com autenticação PLAIN sobre TLS.

14 5.2. Relaying de mensagens a clientes locais Para implementar o teste de relaying para utilizadores locais vai-se utilizar o telnet a correr numa máquina emulada com Ubuntu, mas dentro da rede do servidor, não sendo a rede do LGSR , mas a rede criada pelo VMWare para cenário de teste, Figura 16 Envio de mensagem por telnet de um utilizador na rede local para um endereço externo. Na figura 16, pode-se observar todo o processo, desde a ligação, à definição dos parâmetros da mensagem até ao envio. Com o comprimento do servidor pode-se comprovar que o cliente encontra-se na mesma rede. De seguida vai-se observar o ficheiro do maillog. Figura 17 maillog. Na figura 17 pode-se observar o registo do log, resultante do envio do mail para o exterior. Como se pode observar na figura 16, não foi efectuado qualquer acção de autenticação. De seguida vai-se verificar a caixa de correio de ricardo.mendao@gmail.com. Figura 18 Caixa do gmail.

15 Figura 19 Detalhes da mensagem recebida no gmail. Na figura 18 e 19 pode-se comprovar a recepção do mail na conta externa do gmail, existe um desfasamento de 1 minuto no tempo, devido à não sincronização dos relógios intervenientes. A figura 19 demonstra todos os detalhes da mensagem, sendo que alguns desses detalhes irão ser explicados no ponto 5.5. deste relatório, visto tratarem-se de uma outra questão Relaying de mensagens a clientes externos Para testar o relaying a clientes externos, criou-se uma rede virtual privada, entre o servidor (FC6) e um cliente (ubuntu). O teste vai ser efectuado através de telnet e a primeira simulação irá ser de fracasso, ou seja, sem que o cliente efectue autenticação. Para tal, simulou-se uma ligação a partir de uma rede externa, como se pode observar na figura seguinte.

16 Figura 20 Tentativa de ligação sem autenticação a partir de uma rede externa. Simulou-se uma máquina da aol.com e ao tentar enviar um mail para uma conta gmail.com, através do servidor criado,foirecebida a m ensagem Relaying denied.proper authentication required. De seguida vai-se efectuar a simulação mas desta feita, utilizando autenticação.

17 Figura 21 Envio do exterior com autenticação. Como se pode observar na figura 21, efectuou-se a autenticação inserindo os dados codificados em base64. Como a autenticação foi efectuada com sucesso, o RCPT foi aceite e a mensagem enviada. De notar que neste teste e para simular as redes apresentadas no vmware, perdeu a conectividade com o exterior a partir do servidor criado, contudo o objectivo deste teste é comprovar a aceitação de relaying por parte do servidor, de um cliente situado fora da sua rede local. Figura 22 ficheiro maillog. Como se pode observar no maillog, o servidor efectuou o relaying de um pedido a partir da rede do ipt.aol.com. Na última linha pode-se ver que o mail não saiu do servidor local, mas por problemas de conectividade e não por problemas no sendmail.

18 5.4. Encapsulamento do endereço de origem O endereço de origem, das mensagens enviadas através do servidor criado, seguem com o domínio gsr05.dei.uc.pt. De seguida para demonstrar tal funcionalidade vai-se enviar uma mensagem com o mail de destino de domínio pcg5105.dei.uc.pt e ver o resultado. Figura 23 envio de mail com o destino de domínio pcg5105.dei.uc.pt De seguida vai-se observar a caixa de correio do root e ver de quem recebeu ele a mensagem. Figura 24 Mail recebido pelo root. Com o se pode observar a 4 linha a contar de baixo,nom eadam ente o From :,indica que o m ailveio de Ricardo Silva <rnsilva@ gsr05.dei.uc.pt>, quando na figura 23,na parte do M AIL FRO M : foi introduzido rnsilva@pcg5105.dei.uc.pt, comprovando o sucesso da mascara implementada.

19 5.5. Redireccionamento de correio com destino ao exterior Neste ponto vai-se utilizar o exemplo dado no ponto 5.2. deste relatório, para tal à que observar novamente a figura antes apresentada. Copia Figura 19 Detalhes da mensagem recebida no gmail. Como se pode ver, quando o utilizador local enviou o mail para um utilizador externo, neste caso de uma conta no gmail, esse mail foi redireccionado do servidor criado, para o servidor principal sm tp.dei.uc.pt e então seguiu para fora. Copia Figura 17 maillog. Também no ficheiro de log resultante, pode-se ver o relay=sm tp.dei.uc.pt,que com prova a utilização do servidor de central.

20 5.6. Comando VRFY e EXPN Por questões de segurança não é correcto fornecer os comandos VRFY e EXPN, para tal através de um comando no ficheiro pcg5105.mc, apresentado no ponto 4.2, nomeadamente define(confprivacy_flags,goaw ay),esses com andos deixam de estar disponíveis, como se pode comprovar pelas imagens seguintes. Figura 25 teste ao VRFY e EXPN Para efectuar o teste, realizou-se uma ligação telnet ao servidor. Ao pedir um VRFY rnsilva o servidor deu a resposta Cannot VRFY user...,e ao pedir um EXPN rnsilva,o servidor indicou mesmo que não está autorizado a tal operação. Para melhor comprovar o sucesso desta operação pode-se observar a figura 26, onde se demonstra claramente o registo da rejeição dos pedidos. Figura 26 maillog

21 5.7. Utilizadores não suportados Para implementar a funcionalidade de suportar uma lista de utilizadores, para os quais se nega o acesso ao serviço de correio electrónico, foi utilizado no ficheiro de configuração o com ando FEATU RE(`blacklist_recipients ), que perm ite com que se introduza no ficheiro access.db,filtros destinados a utilizadores locais,do tipo To: badusers Error: 550 M ailbox disable. Para testar tal funcionalidade, o utilizador rnsilva tentou enviar um para o grupo badusers,utilizando a aplicação O utlook Na figura que se segue será apresentado o que o utilizador rnsilva recebeu após tentar enviar o ao grupo. De seguida pode-se observar o registo que ficou no maillog do servidor. Figura 27 Mail de retorno. Figura 28 - Maillog

22 6. Dúvidas e funcionalidades não cumpridas Para teoricamente obrigar o utilizador a efectuar autenticação sobre TLS, seria necessário adicionar as opções p e y ao confau TH_O PTIO N S, contudo ao adicionar estas opções,a opção de autenticação desaparece no Telnet. Talvez até tenha a sua lógica e talvez só fique disponível após o arranque do STARTTLS, contudo foi um ponto não aprofundado e não considerado neste trabalho. 7. Conclusão Devido à importância do correio electrónico na sociedade actual, tornou-se bastante útil a realização deste trabalho, que levou à aquisição de conhecimentos base, que servirão de plataforma para um eventual futuro profissional na área de gestão de servidores de correio electrónico. Para ajudar, à compreensão de todo este sistema, foi também bastante importante a presença das matérias anteriormente abordadas, tanto na cadeira de Gestão de Sistemas, como em Segurança de Sistemas. Quanto ao sendmail, é uma aplicação funcional, mas não muito linear, sendo que com o sistema de macros a sua configuração até é acessível, contudo para quem realiza o primeiro contacto com a ferramenta, depara-se com a dificuldade resultante da vasta documentação a contrastar com a falta de exemplos práticos aliado à dispersão da informação, o que torna a configuração desta ferramenta algo demorada. Concluindo, realizou-se mais um trabalho que aborda uma área de grande importância, da qual actualmente todas as grandes empresas estão dependentes, exigindo cada vez mais dos sistemas e de quem os gere.

23 8. Bibliografia [IETF82] [wikipedia06] [IETF01] [jgranjal,psimoes0607] [wikipedia06a] [sendmail06] [dovecot06] [IETF97]