Caracterização de um Servidor de - Estudo detalhado do seu funcionamento -

Transcrição

1 Caracterização de um Servidor de - Estudo detalhado do seu funcionamento - Neste documento pretende-se descrever de uma forma detalhada o funcionamento de um servidor de . Esta descrição tem como base o funcionamento dos servidores de mais utilizados: Sendmail, Postfix e Microsoft Exchange. 1. Requisitos Não Funcionais Um servidor de para além de satisfazer os requisitos funcionais, deve também satisfazer um conjunto de requisitos não-funcionais (requisitos de arquitectura). Os mais importantes são: a segurança e a fiabilidade, como descritos de seguida [1] [2]: Segurança - Um servidor de deve ser seguro contra os ataques, de modo a não comprometer o sistema. A segurança deve ser efectuada em multi-níveis. Só aos processos importantes é que devem ser atribuídos mais privilégios, os outros devem ser executados com os privilégios sempre mais baixos. Os módulos que não estão em uso devem ser desactivados para que não sejam de alvo de estudo por parte dos atacantes. Fiabilidade Um servidor de deve ser fiável. Não deve perder nenhuma mensagem, mesmo em períodos de maior carga (stress). Pode sempre demorar mais tempo do que normal, mas deve fazer sempre a entrega das mensagens. Existem outros requisitos como: Desempenho Um servidor de deve ser eficiente mesmo em casos de elevado fluxo de mensagens, procurando sempre aproveitar da melhor forma todos os recursos disponibilizados pelo Sistema Operativo. Deve mostrar um bom desempenho sem perder a fiabilidade. Flexibilidade - Um servidor deve ser composto por vários programas e subsistemas. Esta abordagem permite uma maior flexibilidade. Normalmente o seu funcionamento é configurável através de simples ficheiros de configuração. Robustez - Em caso de falta de recursos (por exemplo: memória, disco, etc) um servidor de deve baixar o seu desempenho de uma forma suave. Diminuir apenas a qualidade de serviço (QoS), mas deve garantir o funcionamento mínimo. Deve também registar todas as ocorrências de erros nos logs. Disponibilidade - Um servidor de deve estar sempre disponível. Deve saber defender dos ataques do tipo DoS (Denial-of-Service). Extensibilidade - Um servidor de deve suportar os protocolos de transferência existentes, mas também deverá ser facilmente extensível para suportar novos protocolos. Do mesmo modo, fácil também de implementar de novas funcionalidades. Manutenção - Um servidor de deve ser implementado de modo a que a sua manutenção seja facilmente realizada.

2 2. Arquitectura Um servidor de pode ter diferentes arquitecturas: Sistema monolítico, que tipicamente utiliza um único programa no atendimento das mensagens de ; Programas mais pequenos que executam funções ou tarefas específicas. Muito destes programas são daemons, processos em background que se executarem indefinidamente. Pode-se ter um processo principal, normalmente designado por mestre que controla os outros processos. É neste tipo de arquitectura que é abordada do modelo apresentado de seguida, que é constituída por pequenos componentes e fáceis de entender. Do ponto de vista funcional, um servidor de mais simples deverá ter três grandes componentes: um que é responsável por receber os s; um que faz o processamento; um que é responsável pela entrega dos s. 2.1 Entrada de s no sistema As mensagens de podem entrar no servidor de uma das seguintes maneiras: 1. A mensagem pode ser aceite localmente, recebida do próprio servidor. 2. A mensagem é recebida de outros domínios autorizados; 3. Servidor de gera mensagens quando: envia notificação de s não entregues (undeliverable); adiamento da entrega (deferred delivery attempts); notificações de entrega, gerados a pedido do utilizador (return receipt). 2.2 Espera e processamento Neste componente as mensagens são colocadas em filas de espera e é efectuado o processamento das mesmas. O gestor de filas de espera é um elemento essencial nos servidores de , pois é este o responsável pelo escalonamento das mensagens. Alguns servidores de têm como requisito que todas as mensagens que entram ou saem do sistema, sejam processados através das filas de espera. Cada fila, indica também o estado de processamento da mensagem.

3 Pode-se ter: - Diferentes categorias/classes filas de espera; - Múltiplas filas de espera (para a mesma categoria/classe); - Diferentes tamanho (a capacidade da fila); 2.3 Entrega de s A entrega pode ser efectuada via vários agentes: Local O destinatário pertence ao mesmo servidor. Outros destinatários O destinatário pertence a noutro domínio. Outros tipo transporte Entrega a outro tipo de transporte/programas. De seguida apresenta-se dois exemplos, mas podem existir outros: a) LMTP (Local Mail Transfer Protocol) Permite a transferência das mensagens de de um serviço de correio local para outro, sem a necessidade de existir uma unidade de armazenamento em comum. Assim permite a entrega a unidades de armazenamento não normalizadas. Baseado e uma versão simplificado do protocolo SMTP. b) pipe entrega das mensagens a outros programas através do processo pipe, ou seja, comunicação entre processos. 3. Descrição do Modelo Num servidor de , os elementos que enviam e os recebem os s podem ser classificados em duas classes: Local Pertencem ao mesmo servidor; Remoto Pertencem a outros domínios. De um modo geral tem-se dois casos: Um servidor de recebe mensagem de remetente local, o qual transfere para um destinatário local ou remoto dependendo do endereço de . Um servidor de também pode receber mensagem de outros servidor, sendo este transporte efectuado de acordo com o protocolo SMTP. Se a mensagem é destinada a um utilizador local, então a mensagem é depositada na caixa de do respectivo utilizador. Caso contrario é enviada para o outro servidor de do respectivo domínio. No modelo proposto existe um programa 'mestre', que está sempre em execução. Este invoca novos processos para fazer a leitura das filas de espera e o seu processamento.

4 3.1 Entrada Local Recebe as mensagens com origem no próprio servidor. SMTP Recebe as mensagens de outros servidores, normalmente via o protocolo de transporte SMTP. Tanto processo 'Local' como o 'SMTP', colocam as mensagens na fila de espera para que sejam atendidas por outro processo. O 'SMTP' antes de colocar na fila, verifica se a origem é um domínio ou um remetente autorizado (controlo de acesso). 3.2 Espera e processamento Filtragem Determina quando novas mensagens estão disponíveis por consulta da fila 'submetidas'. Responsável por filtragem dos s em vários níveis: Processa os cabeçalhos dos s e faz a formatação dos mesmos. Verifica o formato dos cabeçalhos, se estão de acordo com o formato definido. Adiciona alguns campos como From:, Message_ID: e Date: Pode fazer a reescrita dos endereços, em função dos valores pré definidos de mapeamento (presentes em tabelas ou base de dados).

5 Controlo - Responsável pela gestão das filas de espera e pela distribuição das mensagens aos diversos agentes de entrega: Espera pela chegada de novas mensagens na fila 'Activas' e depois efectua a distribuição. O gestor de filas de espera responsável pelo escalonamento das filas, que garanta uma distribuição rápida e justa da entrega dos s para todos os destinatários dentro dos recursos que dispõe. Entre o processo 'Filtragem' e 'Controlo' pode existir várias filas de espera. No modelo apresentado tem-se duas filas, mas podem existir mais. Activas Neste fila estão as mensagens que estão a ser processadas pelo 'Controlo' para fazer a entrega ao agente. Adiadas Quando a entrega não é possível devido a falhas temporárias, as mensagens são colocadas nesta fila. As quais são novamente submetidas depois de um tempo pré-definido. As mensagens corrompidas, em alguns servidores são colocadas numa outra fila. Ou pode-se ter uma conta de para depositar este tipo de mensagens. 3.3 Entrega Local A entrega local é atendido pelo processo 'Local' que deposita a mensagem na respectiva caixa de . Mas antes de proceder à entrega, este verifica se existem aliases para o utilizador em questão, em caso afirmativo, a mensagem é enviada para o respectivo endereço (é novamente submetida). Cliente SMTP Quando a entrega destina-se a outro servidor de , o servidor em questão para a desempenhar a função de cliente. O processo 'Controlo' efectua o pedido de entrega ao processo 'Cliente SMTP'. Cada pedido específica a fila, o endereço do remetente, o domínio ou o host do destino e informações do destinatário. Sendo que o destino é determinado pelo serviço de DNS. Outro tipo de transporte Pode ser a outros tipos de transportes, ou a programas externos. (descrito anteriormente)

6 4. Configurações As configurações de funcionamento normalmente estão em ficheiros, onde os parâmetros desse ficheiros são lidos pelos processos do servidor de . (no MS Exchange não sei como é) Os servidores de devem responder em conformidade às definições presentes nas configurações. Em caso de modificação de confirmações com o servidores de em execução, estas devem ser actualizadas com o mínimo de impacto no funcionamento do sistema. Principais configurações Lookup tables As lookup tables servem para armazenar e procurar informações sobre o controlo de acesso, reescrita dos endereços e mesmo para filtragem de conteúdo. Em geral, apresentam o seguinte formato: chave valor chave valor Estas tabelas são ficheiros indexados que permitem o acesso rápido aos valores armazenados. Existem muitas implementações de lookup table, deste simples ficheiros de texto até mesmo ligações com base de dados e servidor LDAP. Ficheiros Aliases Os servidores de têm normalmente associado um ficheiro ou localização de um outro tipo de meio, que contém as informações relativas aos aliases. Os aliases podem ser declarados em estruturas do tipo lookup tables. Normalmente não é possível a utilização de alguns nomes de alises que são restritos à administração do sistema, por exemplo postmaster, root, etc. O RFC 2142 define um conjunto de nomes para as caixas de que todos os domínios devem possuir, dependendo dos serviços que têm em execução no seu domínio (postmaster, webmaster, etc.). Outras considerações de configuração Existem muitas outras considerações que merecem atenção na sua configuração, como exemplo: Configuração da identidade do MTA - Deve-se definir bem quais as informações são expostas aos utilizadores, tendo em conta que estas poderão ser utilizadas para potenciais ataques. Controlo de Relay - Deve-se definir bem quem é que tem acesso autorizado para a utilização dos recursos do sistema como relay. Tendo em conta que deve-se restringir ao máximo este tipo de acesso. O controlo de relay permite também minimizar a circulação das mensagens SPAM. Pode-se limitar o acessos a determinados endereços de IP, mas no caso de endereços dinâmicos isto complica-se pois este tipo de controlo não vai permitir o acesso a um utilizador que devia ter acesso. Para contornar este tipo de problema, recorre-se a mecanismos de autenticação SMTP (descritas mais à frente).

7 5. Administração Logging Todas as operações efectuadas bem como os seus resultados, devem ser alvo de registo. Nos registos devem constar as operações efectuas com sucesso, os erros e os avisos caso tenham ocorrido. Regularmente os registos de log, devem ser analisados, no sentido de determinar como é que o sistema está a comportar, e em caso apresentar anomalias estas poderão ser mais facilmente resolvidas com a ajuda dos registos. Deve-se também definir a capacidade dos logs, ou seja, depois que limite é que começa a eliminar ocorrências de registos. Controlo sobre o estado do servidor de O administrador do sistema deve saber sempre o estado do sistema, bem como o total controlo sobre o mesmo. 6. Limitações e capacidades Limitar a execução de processos a determinadas contas e grupos. Limitar os privilégios que cada processo tem. Limitar o número de processo que podem ser invocados simultaneamente. Limitar o números de vezes que um cliente tenta efectuar operações inválidas, pois poderá ser um ataque. Com possibilidade de definir um tempo a partir do qual poderá novamente efectuar o pedido. 7. Processamento dos endereços Verifica se o endereço está correcto caso contrário efectua as alterações no sentido de ficar com o formato permitido, por exemplo pela adição do domínio ao nome do utilizador. O formato para os endereços no modelo da Internet estão definidos no RFC Capacidade de reescrita do endereço em diferentes formatos. Pode-se ter activado a opção de completar automaticamente o endereço de no formato FQDN - fully qualified domain name. Canonical addresses Permite a reescrita de endereços num formato normalizado/comum por exemplo dentro de uma organização. Muitas vezes é utilizado para fazer o mapeamento de endereços internos em endereços públicos. Masquerading Hostnames Masquerading permite ocultar o nome do host interno, e faz com que todos os endereços tenham sido originados do host gateway. Exemplo: Endereços tipo manuel@seridor1.exemplo.pt e ricardo@seridor2.exemplo.pt são convertidos em manuel@exemplo.pt e ricardol@exemplo.pt. Unknown users Normalmente os endereços inválidos são rejeitados, mas pode-se implementar um mecanismo de tratamento dos mesmos, por exemplo criar um endereço que recebe todos os s dos endereços inválidos.

8 8. Gestão de filas de espera O gestor de filas de espera é um dos componentes mais importantes de um servidor de . Todos as mensagens de entrada como as de saída, devem passar através das filas de espera. Tal como referido existem diferentes filas em função do estado de processamento da mensagem. O administrador deve possuir ferramentas que auxiliem na gestão das filas. Deve-se garantir que o espaço em disco das filas de espera não ultrapassa o limite permitido. 9. Segurança Autenticação SASL O protocolo SMTP base não permite nenhum mecanismo de autenticação dos utilizadores. Como o endereço dos s é fácil de falsificar, torna-se difícil determinar o verdadeiro remetente da mensagem, a não ser que o servidor tenha a capacidade de fazer a autenticação dos utilizadores. Para prevenir de usos não autorizados, pode-se limitar a utilização a determinados endereços IPs. Mas com isto surge o problema quando os utilizadores têm endereços dinâmicos nas suas ligações ao servidor. O RFC 2554 SMTP Service Extension for Authentication fornece uma extensão do protocolo SMTP, que permite a autenticação dos clientes através do protocolo SASL. Pode-se adicionalmente recorrer ao TLS. O TLS é o método de encriptação de dados mais utilizado na comunicação Webserver e browsers, mas também pode-se utilizar para os servidores de e os seus clientes. Sendo que em alguns mecanismos de SASL a password é transmitida em claro, podes-e recorrer ao TLS que envia a password em canais seguros. SASL = autenticação + encriptação SASL Visão geral Em primeiro plano tem como objectivo fornecer mecanismo de autenticação dos utilizadores perante o servidor. O funcionamento do SASL, necessita de saber: Mecanismos de autenticação desafios e respostas entre o cliente e o servidor, e como estas devem ser codificadas para a transmissão. Framework de autenticação refere-se como o servidor guarda e verifica a informação relativa à password. TLS Visão geral Fornece encriptação dos dados ponto-a-ponto. Encriptação a nível da aplicação. SPF - Sender Policy Framework SPF permite combater a falsificação de endereços de retorno dos s (return-path). O mecanismo permite: ao administrador de um domínio: definir e publicar uma política SPF, onde são designados os endereços das máquinas autorizadas a enviar mensagens em nome deste domínio; e ao administrador de um serviço de estabelecer critérios de aceitação de mensagens em função da verificação das políticas SPF publicadas para cada domínio.

9 10. e DNS Os registos de DNS de diferentes registos oferecem vários tipos de informação, tais como endereços IP, nameservers, hostname aliases e mail routing. Os registos necessários para o serviço de são: A Mapeamento de nomes em endereços IP. CNAME Apontam para outro hostname em vez do endereço IP. MX Informações sobre o mail-routing. PTR Mapeamento inverso, endereço IP em hostname. No DNS, o registo MX refere-se ao servidores de . O registo MX contem informações sobre o servidor e a prioridade (ou preferência) para o envio de s nesse domínio. Podem existir mais registo do tipo MX, que correspondem a servidores de com uma prioridade mais baixa que funcionam como servidores de backup. Ou seja recebem os s até que o principal volte em funcionamento Routing Let's consider for a moment one way that routing might work. A user horatio in the domain example.com has a workstation named denmark. He could receive mail by using the address horatio@denmark.example.com. An MTA with a message to deliver would simply look up the IP address for denmark.example.com and deliver it to that system for the user horatio. This scenario requires that Horatio's workstation is always turned on, that it has a functional MTA running at all times to receive messages, and that it is accessible by unknown MTAs from anywhere on the Internet. Rather than manage hundreds or thousands of MTAs on workstations and expose them to the Internet, nearly all sites make use of mail hubs that receive all the mail for a domain. MTAs such as Postfix need a way to determine which host or hosts are the mail hubs for a domain. DNS MX records provide this information. A mail exchanger either delivers mail it receives or forwards it to another mail system. A domain may have multiple mail systems for reliability, and therefore multiple MX records. Generally, one host is the primary mail server and the others serve as backup or secondary mail servers. Each MX record in DNS contains a preference value that orders mail systems from most preferred to least preferred. If no MX records are found for a domain, an MTA checks to see if there is an A record associated with the domain name itself. If there is an A record, the MTA attempts delivery to the system at that IP address Outras funcionalidades que deve apresentar: Gestor de lista de distribuição; Gestão e controlo de mensagens SPAM; Filtragem de conteúdo; Ligação a base de dados externas.

10 Referências [1] Kyle Dent. Postfix: The Definitive Guide. O Reilly Media, Inc., 1st edition, December [2] M. Hafiz. Security architecture of mail transfer agents. Master s thesis, University of Illinois at Urbana-Champaign, [3] Postfix Web Page. [4] Bryan Costales, Claus Assmann, George Jansen, and Gregory Shapiro. Sendmail, 4th Edition. O Reilly Media, Inc., 4 edition, October 2007.